








A Testbed For The Imagination 



SES /workbench 


Simulation and modeling 
software for designing 
large, complex systems. 


Reader Service Number 1 


System complexity... ever increasing, it requires sophisticated 
tools for its management. And, as complexity increases, the costs 
of flawed design decisions increase with it. 

If you design. ..complex hardware systems, software systems, 
communications systems, or VLSI circuitry, you know the 
consequences of discovering a subtle flaw late in the develop¬ 
ment cycle. 

What if... you had an easy to use, elegant tool that could 
determine the impact of design decisions when they are made, 
not weeks or months later? 

Introducing. ..a multi-level simulation, modeling, and design 
evaluation tool that will let you test your ideas, not regret them: 

SES /workbench. 

Call 512-474-4526, write to us 
or check the reader response 
card for more information. 


Test the design, not just the 

Scientific and Engineering Software, Inc. 

1301 West 25th, Suite #300, Austin, Texas 78705 
Phone: 512/474-4526 Fax: 512/479-6217 

See us at the Design Automation Conference in Las Vegas, June 25-29. 






BEFORE 


NEW FOR TELECOMMUNICATION ANALYSTS 

AFTER 



Unrealistic simplifications of analytical methods-costs 
and delays of programming 


Realistic simulation of your telecommunication 
network-quick results, no programming 


See your proposed circuit or packet-switched network perform 

COMNET II.5 now gives you easy-to-understand network 
simulation results quickly-no programming 


W ith COMNET II.5 you 
simply describe your tele¬ 
communication network and its 
routing algorithms. 


Simulation follows immediately 
--no programming delays. 


Easy-to-understand results 

You get an animated picture of 
your network. Routing choices and 
changing levels of network utiliza¬ 
tion during the simulation are ap¬ 
parent. 

Your reports show blocking 
probabilities, call queueing and 
packet delays, network throughput, 
circuit group utilization, and circuit 
group queue statistics. 

Animation increases everyone’s 
understanding of the network oper¬ 
ation and builds confidence in your 
analysis. 


Free trial and training offer 

The free trial contains everything 
you need to try COMNET II.5™ on 
your computer. 

You may develop your own net¬ 
work or modify one of ours. 

Try the COMNET II.5 approach, 
the quality and timeliness of our 
support, the accuracy of our 
documentation, and the facilities 
for error checking-everything you 
need for a successful project. 

For 26 years CACI has offered 
trial use of its simulation software 
-no cost, no obligation. 

Act now-free training offer 

For a limited time we also in¬ 
clude free training. Typical applica¬ 
tions are demonstrated. 

Call today to avoid disappoint¬ 
ment-class size is limited. 


Your network simulated 

You can analyze any wide-area 
network which uses circuit switch¬ 
ing, message switching, or packet 
switching. Virtual-circuit or data¬ 
gram operation can be modeled. 

Various alternate-routing and 
adaptive shortest-path routing 
algorithms are built-in. 


For immediate information 

Call Kelly Cox at (619) 457-9681, 
FAX (619) 457-1184. In the UK, 
call Richard Eve on (01) 528-7980. 

The quickest way for you to 
evaluate telecommunication net¬ 
work alternatives is with COMNET 
n.5. 


COMNET 0.5 results are 
realistic-the drastic simplifying 
assumptions required by analytical 
methods are eliminated. 


Rush information on 
the COMNET II.5 free 
trial and training offer 

Free trial- see for yourself how COM¬ 
NET II.5 quickly answers telecommunica¬ 
tion network performance questions by 
eliminating programming. 

Limited offer-Act now for free training. 
□ Send information on your Special Uni¬ 
versity Offer. 
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HAMBURG • MAY 8-12, 1989 


Main Conference Topics: 

1. VLSI, External Memories and Storage 

Storage systems and devices based on semiconductor, magnetic, optical and other technologies • Hierarchies 
and system architectures of external memories and storage • Intelligent interfaces to peripheral memories 

2. VLSI and I/O Terminals 

I/O Systems and Devices for the Human Interface • Displays e. g. CRT, LCD, ELD, PDP • Printers, e. g. inkjet-, 
thermal-, laser-printers • Keyboards, digitizers, scanners, mouse devices • Speech I/O • Human factors, e. g. 
noise-, glare-reduction, paperhandling, SW-assisted functions 

3. VLSI, Sensors and Controls 

Smart sensors, smart actuators, and data processing systems applied in: robotics, process control, automotive 
and traffic control, medical-, environmental-, alarm- and security systems etc. 

4. VLSI and Computer Communication 
Smart solutions for communication with peripherals: 

Advanced bus systems for direct attachment of peripherals to workstations and host systems • Advances in 
industrial Local Areal Networks for plant floor automation, extended office systems etc. ■ Integrated networks, 
the capacity of ISDN and other integrated networks to support peripherals ■ Heterogeneous communication 
systems, supporting a mix of peripherals from one or more manufacturers 

5. VLSI technologies and Trends 

Selections of technology • Standard vs. custom design • Advanced design tools • Design for noisy environment • 
Low temperature technology • Packaging • Advanced testing concepts 


• Tutorials • Technical Exhibition 

• Presentations • Technical Excursions 

• Plenary Session 


Register Now! - Ask for Final Program 


Please ask for more information 

Prof. Dr. Walter E. Proebster, IBM Deutschland GmbH, Dept. 3101, 7030-14, Schoenaicher Stralte 220, 7030 - Boeblingen, FRG 
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C DEBUGGER $89.95 C COMPILER $89.95 


Zortech’s Debugger is the most 
sophisticated source level debugger now 
available. Because it is fully compatible 
with CodeView you can use it to debug _____ 
Zortech or Microsoft programs. 

Single step through source in one \ ^ ,*..1x9.95 
window while watching the variables \ 

(inc. automatics) change value in 
another window. You can even alter 
variables dynamically while the program 
executes. 

Much better than CodeView, and full of 
advanced features like dual monitor, EMS 
memory and Mouse support. Call for data 
sheet. 


C VIDEO $299.95 

Learn C Now! When you buy our C 
Course the first lesson you learn is in 
economics. You will save yourself or your 
company hundreds of dollars in seminar 
tuition fees. 


Bg 

B 


You get ten one hour tapes containing 36 
lessons ranging from the beginners 
introduction through to more advanced 
features. 

Great for learning C! Any compiler and 
any op erating syst em. Complete with 365 
■page workbook (addi¬ 
tional copies available 
1 at $29.95) and free 
1 Zortech C compiler - 
1 Call for data sheet. 



All our products are covered by 
an extensive FREE technical 
support hotline which is open 
five days a week from 9.00 till 
5.00 (EST) 

USA HOTLINE 
617-646-6703 
Fax: 617-648-9340 

OUTSIDE USA 
44-423-501552 (England) 

Fax: 44-423-530746 (England) 




The most advanced C compiler j 
money can buy. No junk - just 
pure performance. 

Magazines are too 
‘embarrassed to 
print our optimized u 
benchmark results - 
they don’t want to upset 
the big guys! 

The 600 page manual comes with a great 
introductory section and lots of solid tech¬ 
nical data and examples. Fully compatible 
with CodeView and the new Zortech 
C Debugger. You get over 400 functions 
and the Flash Graphics package with 
drivers for Hercules, CGA, EGA and VGA 
-the fastest graphics library available! 
Context Sensitive Help, an advanced 
editor/environment, make, touch, five 
memory models, linker & librarian. Library 
Source only $89.95 - Call for data sheet. 


ZC/TC/MSC TOOLKITS 
from $49.95 

Please state which compiler you have. 

COMMS- $99.95 

Full Communications library with support for 
up to 8 ports, Xmodem, Kermit, ANSI, VT52, 
VT100, up to 38,400 baud, etc. 120 page 
manual. 

BTREE- $79.95 

A database function library for C, complete 
with example program and over 50 functions. 
Easy to use with 92 page manual. 

WINDOWS -$69.95 

Enhance your application with easy to use 
multiple text windows. Full demo program 
including 90 page manual. 

PROSCREEN -$69.95 
Generates C source code for your application 
from screens that you draw. Too many 
features to list. 

HOTKEY -$69.95 

Write memory resident applications with this 
TSR function toolkit. Includes example progs. 
SUPERTEXT -$49.95 
WordStar compatible wordprocessor with 
full source code and 256 page manual. 

Over 150 functions. 

CHESS -$49.95 

Learn to write Chess games with this toolkit 
(contains full source). Also includes 
Backgammon and 150 page manual. 
Please request full data sheets. 

'BTREE 


C++ COMPILER 
$149.95 

This is the world’s only true C++ compiler 
for MS-DOS machines - there is no choice. 
Not to be confused with ‘translators’ which 
are slow, expensive, inefficient and not 
real C++ compilers. 

More people use Zortech’s C++ than any 
other C++ on any operating system. 
Zortech strives to ensure full compatibility 
with AT&T C++. 

Zortech C++ contains all the features of 
Zortech C including the C compiler itself 
at no extra cost. Everything is in one neat 
package. Compatible with CodeView and 
the new Zortech Debugger. C++ Library 
Source only $149.95 - Call for data sheet. 
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C++ TOOLS $99.95 

Zortech's toolkit of base C++ classes 
covering a wide range of common 
programming tasks such as bit vectors, 
singly and doubly linked lists, dynamic 
and virtual arrays, binary search tree, 
hash table, BCD maths, time/date/clock, 
directory lists, filenames, interrupt and 
critical error handlers, string editing, text 
windows and editing. 

The 450 page manual also acts as a C++ 
tutorial which introduces the C 
programmer to the world of C++. Callfor 
data sheet. 



C Primer (Sams) - $23.95 
Advanced C Primer (Sams) 

C+ + (Stroustrup) - $29.95 
Oops & C++ (Wiener) - $27.95 


ORDER 

HOTLINE 

1 - 800 - 848-8408 


£ 8 ® 


VISA/MC/COD 

Prices do not include shipping 
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President’s MESSAGE 


Technical activities: 

Planning for the 1990s and beyond 



Kenneth R. Anderson, Computer Soci¬ 
ety president 


T he 1988 Planning Committee 
formulated a set of objectives 
to fulfill the Computer Soci¬ 
ety’s goal to “Be Number One” and 
established a society-wide, global 
framework for long- and short-range 
planning. 

The society has demonstrated its 
competency in setting annual budgets 
and implementing year-by-year plans, 
but reaching our goal of becoming the 
preeminent organization for computing 
professionals worldwide will require a 
longer view with a clear vision of the 
future. Our planning horizon must 
change by an order of magnitude— 
from one year to 10 years. The long- 
range objectives we’ve set require both 
a long-range plan and a strategy for 
achieving those objectives. 

The underlying technology and pro¬ 
gram base for our future programs will 
come from the Technical Activities 
Board (TAB). I have asked Laurel 
Kaleda, vice president for technical 
activities, to report on TAB’s vision of 
the future as it prepares for the technol¬ 
ogy of the 21st century. Her report 
follows. 

Kenneth R. Anderson 


T he Technical Activities Board’s 
goal for this year is to improve 
the vitality of the technical 
committees (TCs) that make up the 
board. To accomplish this, TAB has set 
the following objectives: 

• evaluate TC relevance, 

• increase/enhance TC activities, 

• increase CS member knowledge of 
TC roles, 

• increase TC membership, and 
• improve administrative/financial 
support for all TAB volunteers. 
These goals may seem very basic, but 
they are essential to guiding and direct¬ 
ing the activities of 33 TCs and five task 
forces of various sizes. 

Evaluating the relevance of the vari¬ 
ous TCs is critical to creating and main¬ 
taining an effective technical program 
through these organizations. We know 
that the current set of TCs does not 
cover all member interest areas and that 
new technical and process areas are con¬ 
stantly being developed. TAB uses task 
force teams to investigate promising 
new areas so that they can be evaluated 
outside the formal TC structure. 

Some task forces will become TCs in 
short order, for they have the volunteer 
and member interest to support a series 
of activities for that particular area. 
Some task forces support new initia¬ 
tives, such as new methods of education 
and communication. These efforts, 
when successful, “graduate” from TAB 
to the board(s) best suited for long-term 
efforts. Compusat 88 is one such exam¬ 
ple. This satellite symposium was our 
first effort at exploring videoconferenc¬ 
ing as an educational medium—and a 
successful one at that. We are now 
working with the Computer Society 
Press and the Educational Activities 


Board to determine future directions in 
this medium. 

Currently, we have task forces in four 
other areas: global change, application 
of expert systems, neural nets, and 
professional tools (especially CASE 
tools). We are interested in exploring a 
number of topics during the coming 
year, if they are of sufficient interest to 
our members and volunteers. Just a few 
of these are 

• application of visualization tech¬ 
niques, 

• computers in manufacturing, 

• hypermedia, 

• knowledge-based systems, and 

• parallel processing. 

You can indicate your interest in these 
fields by using the reader service card 
(see box, below right). We’ll use these 
responses, along with statements of 
interest from active volunteers and any 
other information we can think of, to 
determine the best use of our limited 
resources—volunteer time and funding. 

To develop its road map to the 21st 
century, TAB will look for the best mix 
of existing committees and new task 
forces and of older technologies and 
new fields of interest. Just as computers 
continue to change, so should the tech¬ 
nical makeup of TAB. Some of these 
changes will come within well- 
established committees, such as the TC 
for Simulation, whose charter covers an 
evolving field producing ever more 
complex models of systems. 

New efforts, as I’ve discussed, begin 
as task forces, with near-term goals and 
very concrete objectives. This lets us 
look at new initiatives with a minimum 
of risk. New concepts such as neural 
nets are just such technical startups for 
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Laurel V. Kaleda, second vice presi¬ 
dent, technical activities 


TAB. Still other new efforts seem best 
covered by a coordinated effort of two 
or more TCs. Depending on the activi¬ 
ties selected for a new technical subject, 
TAB has some flexibility in working 
with the TCs to match those activities 
and the appropriate volunteer support. 

Along with these varied activities, we 
are seeking much more publicity for our 
efforts. The TCs need to be visible to 
our members, just as our activities need 
to be visible to encourage more active 
volunteer participation. This in turn 
supports more activities and, we hope, 
more participation and more volun¬ 
teers, and so on. Without continued 
interest and participation from a wide 
base of our membership, the scope of 
the technical program won’t matter. 

This somewhat low-tech approach to 
preparing for the high technology of the 
1990s and the 21st century builds on our 
strengths and moves us toward the best 
possible synergy among TCs, task 
forces, and volunteers. The pursuit of 
high-tech activities is most effective and 
best served by well-proven management 
and administrative techniques. Thus, 
we plan for TAB to evolve through the 
1990s and be ready to support the Com¬ 
puter Society’s technical activities in the 
21st century. 

Your comments and ideas are 
solicited. If you are interested in a par¬ 
ticular TC or task force, please refer to 
the accompanying list and contact the 
chairperson directly. To express your 
opinion on the proposed areas, please 
use the reader service card. 

Laurel V. Kaleda 

IBM, L43/098 

5600 Cottle Rd. 

San Jose, CA 95193 


Technical committee and task force chairs 

Listed below are the names, addresses (including electronic addresses, 
where available), and phone numbers of the TC and task force chairs. In 
most cases, the individual’s office phone number is listed first, followed by a 
departmental, message center, or home phone number. Electronic addresses 
in the initial/dot/last name format (for example, 1.kaleda) are for the Com¬ 
puter Society’s own network, Compmail + . 


Technical committees 


Computational Medicine 

James Slagle 
Univ. of Minnesota 
EE/CS Bldg. Rm. 4-192 
200 Union St. SE 
Minneapolis, MN 55455 
(612)625-0329 
j. slagle 

Computer Architecture 

Roger Anderson 

Lawrence Livermore Lab L-306 

PO Box 808 

Livermore, CA 94550 

(415) 422-8572 

rog.anderson 

anderson@lll-crg.llnl.gov 

Computer Communications 

Ronald M. Rutledge 
Oak Ridge National Lab 
M/S 6271, PO Box 2008 
Oak Ridge, TN 37831-6271 
(615) 576-7643 
rxzornlstc. bitnet .rxz 

Computer and Display Ergonomics 

Louis A. Jansen 

IBM, Dept. H29, Bldg. 205 

PO Box 12195 

Research Triangle Park, NC 27709 
(919) 543-7584 
(919) 929-5860 
l.jansen 


Computer Elements 

Ronald Bell 
Unisys 

322 North 2200 West 
Salt Lake City, UT 84116 
(801) 594-5386 
r.bell 

Computer Graphics 

Stephen Levine 
Wang Laboratories 
1 Industrial Avenue 
MS 012-250 
Lowell, MA 01851 
(617) 967-0798 

Computer Languages 

Boumediene Belkouche 
Tulane University 
Computer Science Dept. 
New Orleans, LA 70118 
(504) 865-5840 
b.belkhouche 
bb@tulane 

Computer Packaging 

Martin Freedman 
AMP, Inc. 

PO Box 3608, MS 106-11 
Harrisburg, PA 17105 
(717) 986-7504 
(212) 322-2849 


Help TAB plan by expressing your interest 


TAB is considering five 
areas for investigation by task 
forces. Using the reader ser¬ 
vice card at the back of the 
magazine, circle the appropri¬ 
ate numbers to indicate your 
interest (or lack of interest) in 
the following topics: 
Application of visualization 
techniques 

161 interested 

162 not interested 


Computers in manufacturing 

163 interested 

164 not interested 
Hypermedia 

165 interested 

166 not interested 
Knowledge-based systems 

167 interested 

168 not interested 
Parallel processing 

169 interested 

170 not interested 
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Computing and the Handicapped 

Everett Johnson 
Wichita State University 
Electrical Engineering 
Wichita, KS 67208 
(316)689-3415 
(316) 744-1929 
e.johnson 

Computers in Education 

Doris Carey 
School of Education 
University of Colorado 
Colorado Springs, CO 80933-7150 
(719) 593-3299 
d.carey 

Data Engineering 

Larry Kerschberg 
Information Systems and 
Systems Engineering Dept. 
George Mason University 
4400 University Drive 
Fairfax, VA 22030-4444 
(703)323-4354 
(703)323-3530 

Design Automation 

Ron Waxman 
University of Virginia 
EE Dept., Thornton Hall 
Charlottesville, VA 22901 
(703)620-2117 
(804) 973-9273 
r. waxman 
ronw @ Virginia. edu 

Distributed Processing 

Walter Kohler 
15 Ash Lane 
Amherst, MA 01002 
(508) 467-4564 

Fault-Tolerant Computing 

David Rennels 
Computer Science Dept. 

4731 Boelter Hall 
University of California 
Los Angeles, CA 90024 
(213) 825-4033 
(213) 825-1484 
rennels@cs.ucla.arpa 

Mass Storage Systems 
Ann U. Kerr 
DARPA 

Nuclear Monitoring Research 
Office 

1400 Wilson Blvd. 

Arlington, VA 22209 

Mathematical Foundations 
of Computing 

Christos Papadimitriou 
Dept, of Computer Science 
and Engineering, MC:C014 
UCSD 

La Jolla, CA 92093 
(619) 534-2086 


Yashwant Malaiya 
CS Dept. 

Colorado State University 
Fort Collins, CO 80523 
(303)491-7031 

Microprocessors and 
Microcomputers 

Glen Langdon 
University of California 
Computer Engineering 
Santa Cruz, CA 96064 
(408) 429-2212 

Multiple-Valued Logic 

Dan Simovici 

University of Massachusetts 
Dept, of Mathematics 
Boston, MA 02125 
(617) 929-7966 
(617)731-3297 
d. simovici 

Oceanic Engineering 
and Technology 

Michael Guberek 
Global Imaging 
201 Lomas Santa Fe Drive 
Suite 360 

Solana Beach, CA 92075 

(619)481-5750 

fax:619-481-1258 

Office Automation 

Vincent Lum 
Code 52 

Naval Postgraduate School 
Monterey, CA 93943 
(408)646-3091 
(408) 646-2449 

Operating Systems 

Luis-Felipe Cabrera 
IBM Almaden Research 
650 Harry Rd. 

San Jose, CA 95150 
(408)927-1838 

Optical Processing 

(chair to be appointed) 

Pattern Analysis and 
Machine Intelligence 

J.K. Aggarwal 
University of Texas 
Electrical Engineering 
Austin, TX 78712 
(512)471-3259 
(512)451-4697 
j. aggarwal 
jka@emx.utexas.edu 

Personal Computing 

Steven Ruth 

Dept, of Decision Sciences 
George Mason University 
4400 University Drive 
Fairfax, VA 22030 


Real-Time Systems 
Andre van Tilborg 
Office of Naval Research 
Code 1133 
800 N. Quincy St. 

Arlington, VA 22217 
(703) 696-4303 

Robotics 

Mohan Trivedi 
University of Tennessee 
Dept. ECE 
Knoxville, TN 37996 
(615)974-5450 
(615) 523-5853 

Security and Privacy 
Carl Landwehr 
Naval Research Laboratory 
Code 5542 

Washington, DC 20375 
(202) 767-3381 
landwehr@nrl-css.arpa 

Simulation 

Paul A. Fishwick 
Dept, of Computer and 
Information Science 
University of Florida 
CSE Bldg., Rm. 301 
Gainesville, FL 32611 
(904)335-8036 
fishwick@ufl.edu 

Software Engineering 

Peter Freeman 
National Science Foundation 
1800 G. St. NW, Rm 304 
Washington, DC 20550 
(202) 357-9747 

Internet: pfreeman@note.nst.j 
Bitnet:p.freeman@nsf 

Supercomputing Applications 

Joanne Martin 
IBM Thomas J. Watson 
Research Center 
PO Box 218, Route 134 
Yorktown Heights, NY 10598 
(914) 945-3285 
(914)945-3331 
j. martin 

Test Technology 
Ned Kornfield 
Widener University 
School of Engineering 
Kirkbride Hall 
Chester, PA 19013 
(215) 499-4055 
(609) 667-7020 
n. kornfield 


VLSI 

Don Bouldin 
University of Tennessee 
Dept. ECE 

Knoxville, TN 37996-2100 
615-974-5444 
615 -574-8588 
615-966-8527 

bouldin@sunl .engr.utk.edu 


Task forces 


Applications of 
Expert Systems 
Dan Yurman 
Office of Solid Waste and 
Emergency Response 
US Environmental Protection 
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Guest Editor’s Introduction 

Software Tools 
for Hardware Test 

Scott Davidson 
AT&T Bell Laboratories 


W elcome to the special issue of 
Computer on software tools 
for hardware test. This 
introduction—especially for readers not 
familiar with the field of hardware 
testing—will put the articles in context, 
touch on some major test areas not 
covered in this issue, and give pointers for 
obtaining more information. 

Why an issue of Computer on testing? 
Because the automatic generation of test 
vectors and their evaluation through fault 
simulation are extremely complex and 
time-consuming operations, consuming 
hours and days of computer time. The 
complexity of the circuits on which these 
tools are used is growing faster than the 
speed of the computers on which they run. 
New algorithms and techniques are 
required for both the circuits of today and 
tomorrow. The techniques for solving 
complex problems in the physical sciences, 
such as vectorization and the exploitation 
of parallelism, do not lend themselves to 
solving testing problems. The purpose of 
this issue is to expose these problems to a 
wider audience and, perhaps, stimulate 
research that will find solutions. 


What is test? 

Hardware test can be defined as 
methods of ensuring that circuits and sys- 
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terns are functioning correctly. How can 
they fail? For the purpose of hardware 
test, the circuit can either be manufactured 
incorrectly or fail after manufacture due 
to aging or some external force (such as 
cosmic ray effects or the cracking of a lead 
due to temperature changes). Hardware 
test does not determine whether the circuit 
has been designed correctly; that is design 
verification. Software test corresponds to 
design verification, not hardware test, and 
should not be confused with it. Software 
would have to be tested like hardware if 
replicating a program introduced random 
program errors that could be detected only 
by running a set of input data and compar¬ 
ing program output to expected output. 

That is exactly what hardware test 
involves. After a design is complete, a set 
of test vectors is created (either manually 
or automatically) to drive the effect of 
faults within the circuit to a circuit output 
where the fault can be detected. Test qual¬ 
ity is measured by fault simulation, which 
determines how many faults modeled by 
the simulation are detected by the vectors. 
After the test vectors are generated, the 
vectors and their expected results must be 
moved to a piece of automatic test equip¬ 
ment, which applies the vectors to the 
physical circuit and collects the circuit’s 
output to determine if a fault is present 
within the circuit. Figure 1 shows a simpli¬ 
fied diagram of the testing process. 
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The above scenario—and the balance of 
this introduction—assumes a digital cir¬ 
cuit. The testing of analog circuits is 
equally important, but the theory of ana¬ 
log test lags behind that of digital test and 
is only beginning to receive the attention 
it deserves. 


Issues in test 

The actual test situation, of course, is 
not as easy as described above. Generat¬ 
ing test vectors for digital integrated cir¬ 
cuits is a very hard problem. Sequential 
circuits, those with memory elements, 
might require many vectors to test one 
fault. The time required to generate these 
vectors is too large for VLSI chips such as 
microprocessors. To solve this problem, 
circuit designers use design-for-testability 
techniques. 

One technique, scan design, converts 
sequential circuits into combinational cir¬ 
cuits by chaining all the flip-flops in the cir¬ 
cuit into one or several shift registers. This 
permits using faster combinational test 
generation algorithms for vector genera¬ 
tion. Another technique, built-in self test, 
adds IC hardware to generate random pat¬ 
terns that can be applied to the chip’s com¬ 
binational logic. This has the advantages 
of applying long vector sequences at circuit 
speed and of needing little or no test gener- 
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ation. The disadvantages are that the chip 
becomes more complex and that there can 
be performance penalties. Both of these 
techniques have gained wide and growing 
acceptance as devices become more 
complex. 

The testing problem is not over when a 
good test for the IC exists, however. Chips 
must be put on circuit boards, and circuit 
boards must be assembled into Systems. 
The circuit-board assembly process can 
introduce defects such as shorts, opens, 
and bent wires into boards. Testing for 
these can be done in two ways. 

The first way, called functional testing, 
applies test vectors to board inputs and 
monitors board outputs. Automatic test 
generation for this is even more complex 
than for ICs, and it is impractical for 
boards of reasonable complexity. Tests 
can be generated manually, but fault simu¬ 
lation of circuit boards is expensive and 
time consuming with today’s tools. The 
benefit of functional test is that it tests the 
board with all parts working together. 

The second method, in-circuit test, elec¬ 
trically isolates each board component and 
tests it separately. Libraries of tests for 
commonly used components can be 
assembled, thus greatly reducing the prob¬ 
lem. In-circuit automatic test equipment 
now dominates testing of complex boards, 
but this technique also has problems. As 
boards become denser, access to each com¬ 
ponent’s I/O pins becomes increasingly 
difficult; in fact, test pads often have to be 
added to make this possible. The pins of 
newer surface-mount components are 
inaccessible to the test probes of in-circuit 
testers. 

Just as with ICs, the solution to these 
problems lies in design for testability. The 
boundary scan DFT technique places flip- 
flops at the I/O pins of devices on the 
board. These flip-flops are connected in a 
scan chain, with access to the board’s input 
and output. Boundary scan allows test vec¬ 
tors to be scanned into ICs from the 
board’s inputs. Other benefits of bound¬ 
ary scan are the ability to easily test the 
interconnection between ICs on a board 
and the ability to initiate a chip’s self-test 
features from outside the board. Bound¬ 
ary scan is the subject of a proposed IEEE 
standard, PI 149.1. 

At the system level, the major problems 
are determining whether a failure has 
occurred and, if it has, pinpointing the 
fault responsible for the failure. Systems 
diagnostics for computers and large tele¬ 
phone switching systems are large pro¬ 
grams that exercise as much of the system 



Figure 1. Testing process flow. 


as possible. Because of the complexity of 
these systems, diagnostics are written by 
large teams of programmers and are not 
graded as to quality like test vectors. The 
cost of diagnostics is a major development 
cost of highly reliable systems. 

Trends in test 

Two main sources of problems for test¬ 
ing tools are the complexity of the circuit 
to be tested and the lack of controllability 
and observability of circuit constituents. 
Most test techniques work effectively by 
reducing the complexity of the circuit to be 
tested or by increasing controllability and 
observability. The latter method must be 
accomplished by changing circuit design 
styles, such as using built-in self test, a 
topic beyond the scope of this issue. The 
former is the area attacked by software 
tools for test. 

One method of reducing complexity 
describes the circuit at a higher level. Cir¬ 
cuits are designed hierarchically. Figure 2 



Figure 2. Levels of circuit hierarchy. 


shows some levels of hierarchy. ICs are 
actually composed of transistors, but IC 
designers don’t spend much time thinking 
at this level. Instead, standard collections 
of transistors are used as building blocks. 
These can be traditional logic gates or 
more complex cells built directly from 
transistors for efficiency. Functional 
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How to find out more about testing 

!EEE Design & Test magazine provides continuing coverage of test-related 
issues, including several special issues on test each year. For subscription 
information, see the blow-in postcard in this issue. 

The leading conference in the field is the International Test Conference, 
sponsored by the Computer Society Test Technology Committee and the 
Philadelphia Section of the IEEE. It is held in Washington, DC, in late August 
or early September, with this year’s conference set for August 27-31 (see 
“Calendar,” pp. 109-114, for additional information). Back issues of the 
proceedings are available from the Computer Society Press, Los Alamitos, 
California. To order by phone, call (800) CS-BOOKS or (714) 821-8380 in Califor¬ 
nia, specifying order number 870, 798, or 726 for the 1988,1987, or 1986 
proceedings, respectively. To obtain a copy of the CS Press 1989 publications 
catalog, circle number 201 on the reader service card at the back of the 
magazine. 

The Design Automation Conference also presents relevant papers, espe¬ 
cially on software tools for test generation and fault simulation. DAC 89 will 
be held June 25-29 in Las Vegas (see “Calendar”), and past conference 
proceedings are available from CS Press (#864,1988; #781,1987; and #702 
1986). 

The Test Technology Technical Committee of the Computer Society also 
sponsors several workshops, including the VLSI Test Workshop (April 11-13 in 
Atlantic City), Built-In Self Test Workshop (held last month), and the Design 
for Testability Workshop (April 18-21 in Vail, Colorado). For information on the 
Test Technology TC, contact the chairperson: Ned Kornfield, Widener Univer¬ 
sity, School of Engineering, Kirkbride Hall, Chester, PA 19013; phone, (215) 
499-4055 or (609) 667-7020; Compmail + , n.kornfield. 

Information on the proposed boundary scan standard can be obtained from 
R.E. Tulloss, AT&T Bell Laboratories, PO Box 900, Princeton, NJ, 08540. 


blocks, such as adders, multiplexers, flip- 
flops, and counters, are built of these cells. 
At the next higher level, functional blocks 
are combined into architectural blocks, 
such as arithmetic logic units, registers, 
and buses. At each higher level, the com¬ 
plexity of the circuit description decreases, 
but at the cost of losing implementation 
details. Traditionally, test generation and 
fault simulation have been done at the gate 
level. Since the complexity of these oper¬ 
ations is a function of the number of cir¬ 
cuit components, decreasing the number 
of components results in faster operation 
(though with reduced accuracy). 

This issue contains two articles on 
functional-level testing: “High-Level Test 
Generation for VLSI” by Debashis Bhat- 
tacharya, Brian T. Murray, and John P. 
Hayes surveys current approaches, while 
“Whistle: A Workbench for Test Devel¬ 
opment of Library-Based Designs” by 
Raphael Renous, Gabriel M. Silberman, 
and Ilan Spillinger presents a specific envi¬ 
ronment. 

Test generation involves searching for a 
set of vectors to detect a particular fault 
through the space of all possible vectors. 
Though the complexity of test generation 


cannot be reduced, better search tech¬ 
niques provide better answers faster. The 
article by Wu-Tung Cheng and Tapan J. 
Chakraborty, “Gentest: An Automatic 
Test-Generation System for Sequential 
Circuits,” presents some new techniques 
for sequential test generation through bet¬ 
ter heuristics and data structures. Both test 
generation and fault simulation are driven 
by the fault model, that is, the assumption 
of what can go wrong with the circuit. The 
adoption of the stuck-at fault model, 
which assumes that all faults can be 
modeled by a line being either permanently 
0 or 1, has limited the problem sufficiently 
for progress to be made in test generation. 
The lack of an accepted fault model may 
be a major stumbling block to the success 
of software test. However, the adoption of 
a model does not relieve those in the field 
from constant reexamination of their 
assumptions. One assumption is the exact 
meaning of fault coverage. The article by 
Mark A. Heap and William A. Rogers, 
“Generating Single-Stuck-Fault Coverage 
from a Collapsed-Fault Set,” asks what 
faults should be considered in computing 
fault coverage and shows that many cur¬ 
rent methods give misleading results. 


Purely automatic diagnostic techniques 
are not yet adequate at the circuit board 
level, but more effective problem diagno¬ 
sis can be achieved by providing assistance 
to the person responsible. A system to do 
just that is presented in “The Test 
Engineer’s Assistant: A Support Environ¬ 
ment for Hardware Design for Testabil¬ 
ity” by Jill J. Hallenbeck, James R. 
Cybrynski, Nick Kanopoulos, Tassos 
Markas, and Nagesh Vasanthavada. Their 
work is an early step in developing soft¬ 
ware tools for board and system test. 

In the past 20 years, great strides have 
been made in improving the effectiveness 
of software tools for hardware test, but the 
target moves even faster. More work is 
needed to ensure the quality of the digital 
components we all use.D 
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High-Level Test Generation 
for VLSI 

Debashis Bhattacharya, Yale University 
Brian T. Murray, General Motors Research Laboratories 
John P. Hayes, University of Michigan 


T esting is as vital to the microelec¬ 
tronics industry as to the software 
industry. Very large scale inte¬ 
grated circuits, however, require testing 
for manufacturing defects as well as for 
design faults. The former frequently result 
from the manufacturing process used to 
make the chips and are not easily elimi¬ 
nated. All chips are tested, but companies 
whose products have very stringent relia¬ 
bility requirements generally also have 
strict requirements for testing. The deriva¬ 
tion of tests for chips in this latter category 
typically takes at least one third of the 
design time and makes extensive use of 
special test-generation software. 

VLSI test generation is very complex. 
The test generation problem is NP- 
complete when defined in terms of the 
most common (low-level) circuit and fault 
models, which represent the circuit using 
Boolean logic elements and binary signals. 
Specialized design-for-testability tech¬ 
niques and high-performance computer- 
aided design workstations have held this 
intractability in check, but the design tech¬ 
niques are not without their costs and 
might not always apply. As a result, con¬ 
siderable recent research has focused on 
test generation techniques that give good 
results on wide classes of circuits and 
design styles. Much of this effort focuses 



High-level approaches 
to test generation for 
VLSI circuits can 
significantly reduce 
test generation time 
while still providing 
good fault coverage. 


on what we call high-level approaches , 
which view the circuit with less structural 
detail, that is, from a more abstract view¬ 
point and often hierarchically. 

Circuit and fault 
models 

We first review some basic circuit and 
fault models and the two most widely 
known test generation algorithms as a 


basis for comparison between high- and 
low-level techniques. Circuit models can 
be classified as either structural or 
behavioral. Structural models emphasize 
the fact that circuits are composed of func¬ 
tional modules interconnected by wires or 
groups of wires called buses. Behavioral 
circuit models, on the other hand, attempt 
to ignore circuit structure as much as pos¬ 
sible, concentrating on only a few relevant 
structural details that allow us to define a 
description of circuit behavior. Test gener¬ 
ators using strictly behavioral circuit 
models are generally referred to as func¬ 
tional test generators. 

In higher-level test generation 
approaches, buses are frequently treated 
as primitive logical entities that propagate 
multibit values. Structural models treat 
circuits as graphs whose nodes are modules 
and whose edges are buses. These models 
are usually hierarchical, reflecting the 
standard practice of VLSI design, and are 
well supported by multilevel CAD tools. 
A comparable aspect of software design 
shows up in the use of computer-aided 
software engineering tools. 

An example of hierarchical structure 
appears in the ripple-carry adder in Figure 
1. Figure la shows a structural model of a 
full adder (FA ) module; this is also an 
example of low-level logic design. A 
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Figure 1. Adder viewed at two levels of abstraction: (a) gate and (b) register. 


behavioral description of this circuit is 
given by the following set of Boolean for¬ 
mulas defining the adder’s sum (S) and 
output carry (C,+ i) signals in terms of 
input data (A and B) and input carry (C,) 
signals. 

S : = A © B 9 Q 

C,- +1 : = (A A B) V (A A C,) V(5A Q) 

Figure lb shows a group of FA modules 
connected to form a four-bit adder, which 
is then combined with two registers in the 
design of a simple processor. This circuit 
provides an example of higher-level logic 
design at the register-transfer level. Nets 
A [0:3], £[0:3], etc. are buses defining 
higher-level versions of the binary signals 
in the full adder equations above. The 
operation of this adder circuit can be suc¬ 
cinctly represented by the high-level 
behavioral modeling statement 

S[0:3] : = A [0:3] + £[0:3] 

Faults in ICs primarily result from phys¬ 
ical defects. A variety of disturbances arise 
even in mature fabrication lines and cause 
subtle failures that might not be detected 
for a long time without thorough testing. 


They can later show up as performance 
degradation or as errors in little-used func¬ 
tions, as well as obvious catastrophic 
failures. 

To generate tests, we use logical fault 
models that reflect changes in circuit func¬ 
tion due to physical defects. A digital logic 
circuit is then said to fail if the function it 
implements differs from the function it 
was designed to implement. Fault models 
provide a consistent and technology- 
independent mechanism for how the logic 
function might fail, as well as a standard 
yardstick for measuring the quality of a set 
of tests. 

The most common fault model is the 
low-level single stuck line (SSL) fault 
model. Physical failures are represented by 
maintaining a single line in the circuit at the 
constant value 0 or 1 regardless of how cir¬ 
cuit operation stimulates the line. To test 
if a line is stuck at 0 (1), we must find a 
sequence of one or more primary circuit 
input test patterns or vectors that will 
make the line 1 (0). This exposes the fault. 
The test must also arrange for an error 
caused by the fault to be propagated to a 
primary output. 

Usually, we must find test patterns for 
all 2/VSSL faults in an N-line circuit. Typi¬ 
cally, a given test will detect or cover more 
than one fault. The fraction of faults 


covered by a set of test patterns is called the 
fault coverage. Experience has shown that 
chips tested to provide high fault coverage 
(0.99 or better) for SSL faults generally 
have good reliability in the field. 

Fligher-level fault models are often 
defined in more abstract and less precise 
terms. In Lin and Su’s register-transfer- 
level fault model, 1 for example, faults are 
classified according to their effects on 
some register-level components. They 
include such symptoms as register decod¬ 
ing errors, data-transfer errors, etc. Other 
higher-level fault models are extensions of 
the SSL fault model. For example, 
Bhattacharya 2 extended the single stuck 
fault model to include all bits of a bus, 
leading to the concept of bus faults. 

Test generation 

Traditionally, test generation 
algorithms have been designed to generate 
tests using gate-level structural circuit 
models and SSL fault models. Any hierar¬ 
chy used when designing the circuit is 
removed (the circuit is “flattened”) before 
test generation begins. This simplifies the 
algorithms and provides precise coverage 
measurement. An outline of a generic 
procedure for generating tests for all faults 
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1 procedure test generation 

2 begin 

3 do begin 

4 select an uncovered fault; 

5 generate a test for the fault; 

6 evaluate fault coverage thus far; 

7 end 


Figure 2. Generic test generation procedure. 



Figure 3. An example of 27-propagation in a carry circuit. 


in a circuit appears in Figure 2. 

We will now discuss the two most widely 
used algorithmic test generation 
approaches. Although we describe their 
use on gate-level circuits first, versions of 
these algorithms are used at a variety of 
circuit abstraction levels. In a sense, the 
algorithms represent problem-solving 
approaches rather than specific solutions. 
Note that the main test generation step 
(line 5) in Figure 2 can be further broken 
down into two parts: (1) expose the fault, 
and (2) propagate an error signal from the 
site of the fault to an observable output, 
that is, an output we know how to measure 
directly or indirectly. 

We first introduce some notation used 
in many test generation algorithms for 
describing errors. If a line in a circuit is 0 
(1) when it should be 1 (0), the error signal 
value on that line is represented by the 
symbol 27 (27) for discrepancy. Consider 
the circuit in Figure 3. This circuit is the 
carry part of a full adder (Figure la). A 
stuck-at-0 fault at the output of gate G, 


can be exposed by attempting to make the 
output 1. A signal on this line will be 
detected as an error if it is 0 when it should 
be 1, that is, a 27. G\ stuck-at-0 can be 
exposed, therefore, by assigning 0 to one 
or both of X\ and X 2 . 

Suppose that the output line of G 4 is 
observable, that is, accessible by the test 
equipment used. To observe the fault, we 
must propagate the 27 error signal from 
Gi through G 4 . To accomplish this, we 
must sensitize G 4 to the error signal. We 
can do this only by assigning 1 to each of 
G 4 ’s inputs from gates other than G,. The 
output of G 4 will be 2? as shown, 
which still carries the error information. 

The error propagation step just 
described is generally called 27- 
propagation. Now, the outputs of G 2 and 
G 3 have been assigned specific logic 
values, but not all of their inputs. If Q is 
assigned the value 0, the circuit behavior 
will be completely specified. This process 
of determining complete and consistent 
specifications of circuit signal values is 


called justification. 

The most widely known test generation 
algorithm is the Z7-algorithm, first pub¬ 
lished in 1966. 3 It provides a systematic 
implementation of the 27-propagation and 
justification steps described above^In the 
case of ^-propagation, all 27 s (Ds) are 
propagated simultaneously, since some¬ 
times an error signal must be propagated 
along more than one path to reach an 
observable output. 

Both 27-propagation and justification 
involve choices. For example, to accom¬ 
plish D-propagation in the circuit of Fig¬ 
ure 3, C, could have been assigned 1. If 
D-propagation or justification cannot be 
done at some point without invalidating 
signal values already assigned, the 27- 
algorithm backtracks to an earlier decision 
point and makes an alternative decision. 
For example, an alternative path can be 
followed from a point on the 27- 
propagation path where a signal line 
branches in several directions. 

The 27-algorithm has been successfully 
implemented for many years. Around 
1980, it was shown to be inefficient for a 
useful class of circuits called error- 
correction-and-translation circuits; it 
might be inefficient for other useful cir¬ 
cuits as well. Poor choices for 27- 
propagation and justification in these cir¬ 
cuits lead to an excessive number of back¬ 
tracks and unacceptably long computation 
times. A major reason is the fact that back¬ 
tracking might be initiated at any gate in 
the circuit. 

The Podem (Path Oriented Decision 
Making) test generation algorithm avoids 
this problem by backtracking only at pri¬ 
mary inputs. 3 In Podem, internal values 
are not justified as in the 27-algorithm. To 
satisfy an internal objective such as plac¬ 
ing a 27 or 27 on some internal line, a value 
is assigned to a primary input X, and the 
circuit is simulated. If the simulation 
proves that the assignment does not satisfy 
the objective, the algorithm backtracks by 
changing the value of X r When all values 
have been tried unsuccessfully, the current 
X, will not be used in later trials. In this 
way the algorithm can exhaustively 
explore the input space, but only 
implicitly, so, while the effect of all inputs 
is considered, not all possible input assign¬ 
ments are made. 

The 27-algorithm and Podem, as dis¬ 
cussed thus far, apply to circuits with no 
memory elements. Such circuits are called 
combinational , while circuits that contain 
memory elements are called sequential. 
The latter are much harder to test, but con- 
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siderably more common. A standard low- 
level test generation algorithm can be 
extended for use with sequential circuits by 
repeatedly applying it to the combina¬ 
tional part of the circuit. 3 A test for a sin¬ 
gle fault might therefore require a long 
sequence of input vectors. This greatly 
increases the complexity of the test gener¬ 
ation process, a problem that we can ame¬ 
liorate only by moving to a higher level of 
abstraction. 


Summary of high-level 
approaches 

We now briefly summarize the pro¬ 
posed high-level approaches to test gener¬ 
ation; the remainder of this article 
examines the more important of them. We 
divide them into two broad classes: 
algorithmic and heuristic. The algorithmic 
methods are firmly based on well-defined 
test generation methods such as the D- 
algorithm and Podem. Methods in the sec¬ 
ond class are characterized by extensive 
use of heuristics, and some have been 
heavily influenced by techniques devel¬ 
oped in artificial intelligence research. 
They particularly suit very high levels of 
abstraction where both circuit structure 
and behavior are ill-defined. 

Several of the proposed high-level tech¬ 
niques model the circuit in terms of high- 
level functional blocks interconnected by 
single-bit lines. The fault models can allow 
for arbitrary faults in these blocks, and the 
test generation algorithms used can be sim¬ 
ple extensions of the classical ones 
described above. Somenzi et al. 4 and 
Chandra and Patel 5 provided examples of 
this test generation approach. In contrast, 
the “vector” approach proposed by 
Bhattacharya 2 uses a high-level fault 
model that extends single-line faults to 
buses. 

Another approach to high-level testing 
employs hardware description languages 
(HDLs) that describe circuit behavior at 
the register-transfer level. These languages 
resemble programming languages such as 
Pascal, but have specific features for 
describing hardware and timing features 
of digital systems. 

Thatte and Abraham 6 developed a 
high-level test generation scheme specifi¬ 
cally for microprocessors or related cir¬ 
cuits. It describes normal and faulty 
behavior via a graph model. 

Finally, a number of proposed symbolic 
test generation algorithms 1 ' 7,8 process 


symbolic values representing test vectors 
and other testing-related data. 

The second (heuristic) group of high- 
level test generation techniques derive 
from the observation that test generation 
is a search problem and hence can benefit 
significantly from search techniques devel¬ 
oped for artificial intelligence applica¬ 
tions. In Hitest, 9 developed in the early 
1980s and one of the earliest such systems, 
test generation is viewed as a search 
through a state space constrained by par¬ 
titioning and a small number of heuristic 
rules encoded in a knowledge base. 
Saturn 10 is a test generation system 
intended to reason about a circuit within 
a hierarchical framework. A related 
unnamed system developed at MIT, 11 
which we refer to as MIT-TG, uses knowl¬ 
edge acquired during circuit simulations to 
achieve test generation goals. 


Algorithmic 

approaches 

First, we examine test generation 
methods with well-defined underlying 
algorithms. Several such approaches use a 
model of the circuit under test, which con¬ 
sists of relatively independent high-level 
modules, also termed macros, intercon¬ 
nected by single-bit lines. 4,5 The test 
generation algorithms designed for these 
high-level models are usually direct exten¬ 
sions of classical algorithms, in which the 
functional modules are treated as primitive 
components. Circuits composed of high- 
level modules have fewer primitive compo¬ 
nents, so fewer components must be evalu¬ 
ated during test generation. The potential 
performance advantage of the reduced 
structural complexity makes this approach 
attractive. 

Somenzi et al. 4 presented a set of high- 
level test generation techniques for modu¬ 
lar combinational circuits based on the D- 
algorithm. Their circuit model consists of 
modules interconnected by single-bit lines, 
which ties it to the SSL fault model. More 
recently, Chandra and Patel 5 proposed an 
extension to Podem that can handle 
general primitive components in a similar 
manner. 

Both of these techniques would treat the 
ripple-carry adder presented in Figure lb 
as a primitive module. In addition, both 
approaches provide methods for control¬ 
ling the output values of modules from the 
inputs and for propagating fault effects 
through modules to outputs. Chandra and 


Patel 5 presented data for test generation 
on adders and multipliers showing that the 
number of module evaluations (table 
lookups for propagation and justification) 
decreases and the number of backtracks 
increases. For hierarchical circuit descrip¬ 
tions, the algorithm makes more decisions 
requiring backtracks than it does for flat 
circuit descriptions, but each backtrack is 
less costly than in the corresponding gate- 
level model. 

While the high-level circuit models of 
Somenzi et al. 4 and Chandra and Patel 5 
have fewer modules to evaluate, potential 
performance improvement is limited by 
the use of single-bit interconnections and 
signals. Larger modules have larger num¬ 
bers of single-bit input lines, and the space 
required to store test and propagation 
behavior is exponential in the number of 
inputs. This causes correspondingly long 
table search times. 

Bhattacharya defined a test generation 
methodology 2 that uses high-level inter¬ 
connections (buses) and fault models, in 
addition to high-level modules of the kind 
discussed above. A bus in the circuit is 
called totally stuck at 0(1) if all its lines are 
permanently stuck at logic value 0 (1). A 
high-level algorithm called Vpodem gener¬ 
ates tests for total bus faults in the high- 
level circuit models. 2 This algorithm 
assigns vectors to buses in the high-level 
model, and test patterns are computed 
using a high-level (vector) extension of 
Podem. The circuit and fault models, as 
well as the test generation algorithm, 
reduce to classical ones if components are 
restricted to single gates and bus sizes are 
restricted to one, thus providing a hierar¬ 
chical approach to test generation for large 
circuits. 

The approach taken by Vpodem espe¬ 
cially suits regular circuits like iterative 
logic arrays; the four full adders in Figure 
lb form such an array. In many such cases, 
it can be shown that a test generated for a 
total bus fault in the high-level model is 
guaranteed to detect all SSL faults on cor¬ 
responding lines in a gate-level model of 
the circuit. Experiments conducted with 
medium scale ICs 2 suggest that tests 
generated for total bus faults in the high- 
level model detect more than 70 percent of 
the SSL faults in the corresponding gate- 
level model. The number of tests so gener¬ 
ated is typically less by a factor of n, where 
n bits is the main bus size, than might be 
required to achieve the same fault cover¬ 
age using gate-level models of the circuits 
alone. The smaller number of tests com¬ 
bined with the reduced component count 
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Figure 4. Module-level circuit. 


in the high-level model lead to a reduction 
in the total test generation effort, also by 
a factor of about n, compared to standard 
techniques. Moreover, using Vpodem and 
a gate-level model of the same circuit, we 
can still obtain 100-percent SSL fault 
coverage by generating tests for SSL faults 
not detected by tests for total bus faults. 

Murray and Hayes 8 presented another 
use of symbolic vector sequences. As in 
Bhattacharya’s work, 2 signal values are 
propagated at the bus level; however, no 
particular fault model is assumed. The test 
data for modules are represented by prede¬ 
fined stimulus/response test “packages” 
derived independently using any desired 
fault models. The test packages are 
designed to provide high fault coverage for 
each module tested in isolation. During 
test generation for circuits composed of 
modules, the test packages for the modules 
are processed symbolically by an algo¬ 
rithm similar to the D-algorithm. 

An example of a high-level circuit model 
with bus-type interconnections appears in 
Figure 4. The circuit consists of five types 
of primitive modules: Adderx, Adder, FO, 
MUX, and Latch. Buses 5,12, and 13 are 
one-bit buses; all others contain eight bits. 
Adderx is an adder whose carry-out bus 
has been combined with the most signifi¬ 
cant seven bits of the sum, forming the 
output bus msb. The least significant bit 
of the sum is called Isb. Adder is self- 
explanatory. Latch is an edge-triggered 
latch module. MUX is a multiplexer. FO 
is a “fanout” module that transfers values 
on its input bus to two output buses with¬ 
out modification. 


A key issue in symbolic test generation 
is the propagation of test data through 
modules. In Murray and Hayes, 8 test 
packages are only propagated without 
modification. That is, when the algorithm 
attempts to propagate a test package 
through a module, it only succeeds when 
the module has an attainable state that 
allows the test package to be propagated 
substantially unchanged. This is consider¬ 
ably more restrictive than the problem of 
propagating fault effects (Ds and Ds) on 
individual lines and limits the number of 
circuits that can take advantage of the 
technique. 

However, for circuits where the 
approach applies, the potential speedup 
over gate-level techniques is significant: up 
to three orders of magnitude. Moreover, 
if a test package cannot be propagated 
through a high-level model, a lower-level 
(such as a gate-level) model can be tried, 
if available. As in Vpodem, the algorithm 
reduces to classical test generation if the 
circuit model used is strictly logic-gate level 
and if stimulus/response sequences span 
only a single time instance instead of 
many. 

One measure of the performance of 
high-level test generation algorithms is the 
number of primitive module evaluations 
performed during a test generation pass. 12 
A module evaluation takes place each time 
the module’s output value(s) are computed 
based on input values or vice versa. As 
shown by Goel, 12 a lower bound on the 
number of gate evaluations required to test 
a circuit is Q(G 2 ), where G represents the 
number of gates. An equivalent gate-level 


model for the circuit in Figure 4 has 
G =254, in which case G 2 = 64,516. 

The technique described by Murray and 
Hayes 8 will make a total of 57 module 
evaluations, of roughly the same complex¬ 
ity as a typical gate evaluation, to propa¬ 
gate response packages to prjmary outputs 
and stimulus packages to primary inputs 
for the five modules in the circuit shown 
in Figure 4. Thus, in this particular case the 
high-level approach leads to a speedup by 
a factor of about a thousand compared to 
the conventional gate-level approach. 

Levendel and Menon 13 proposed the 
use of HDL models for high-level test 
generation, again using theZ>-algorithm as 
the basis. This approach was motivated by 
the widespread use of HDLs in describing 
the high-level design of a circuit. They sug¬ 
gested inserting faults into a circuit by 
assignment of D error signals to variables 
in an HDL description of the circuit. They 
also described D-propagation and justifi¬ 
cation techniques applicable to HDL 
descriptions. The strength of this tech¬ 
nique is that it does not require a complete 
structural model of the circuit under test; 
such models are often unavailable for 
VLSI circuits. However, the method 
implicitly uses a fairly low-level fault 
model. As a result, the number of target 
faults to be examined is large, partially off¬ 
setting the usefulness of generating tests at 
the higher level. Levendel and Menon 
reported no implementation of this 
approach, 13 so no performance figures 
can be given. 

Thatte and Abraham proposed a graph- 
based high-level test generation scheme. 6 
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Figure 5. Graph model of an 8-bit microprocessor. 6 


Their method was primarily designed for 
microprocessors and programmable cir¬ 
cuits of a similar nature. It assumes knowl¬ 
edge of the register-transfer operations 
that the circuit can perform, that is, the 
kind of high-level information readily 
available in the description of a 
microprocessor’s instruction set. The 
graph model has a vertex for every regis¬ 
ter in the circuit, input and output ports 
also being treated as two special registers. 
An edge /is inserted from vertex /?, to ver¬ 
tex Rj if the circuit performs a register- 
transfer operation of the form I:Rj •*- /?,. 

Figure 5 illustrates the graph model for 
a simple eight-bit microprocessor (from 
Thatte and Abraham 6 ). In general, data 
transfer operations occurring during the 
execution of an instruction of the 
microprocessor are mapped to paths in the 
graph representing the microprocessor. 
The test generation technique is based on 
the assumption that faults affecting phys¬ 
ical data transfer will cause the following 
of erroneous logical data transfer paths 
when the microprocessor executes certain 
sequences of instructions. These instruc¬ 
tion sequences, derived from the graph 
model, form the desired tests. 


Like the HDL approach, the graph- 
based method has the advantage of a high 
level of abstraction, which makes it 
independent of internal circuit details. 
This independence is especially important 
to designers of microprocessor-based sys¬ 
tems, whose main sources of information 
are data books containing register-level 
descriptions of the microprocessor and its 
support ICs. Thatte and Abraham 
presented experimental data also indicat¬ 
ing that tests generated using this approach 
provided fault coverage in excess of 0.90 
for one microprocessor. 6 Disadvantages 
of the method are its limited scope, a ten¬ 
dency to generate very long instruction 
sequences for some faults, and the inabil¬ 
ity to deal directly with data-path (arith¬ 
metic logic unit) faults. 


Heuristic approaches 

In this section we will discuss how heu¬ 
ristic principles derived from AI are being 
used to improve test generation, primar¬ 
ily through high-level means. Although 
test generation for complicated circuits is 
difficult for humans, an experienced test 


engineer can often generate the required 
tests with the help of a few computer-based 
tools. No known algorithm can duplicate 
this feat. In addition, test generation is 
very much like other NP-complete prob¬ 
lems that AI practitioners try to solve and 
for which they have developed heuristic 
solution techniques. 

AI research into test generation has 
focused on two techniques: abstraction, 
which we discussed earlier, and knowledge 
utilization. Knowledge in this context is 
prestored information directly usable in 
problem solving. Here we will discuss three 
representative Al-influenced test genera¬ 
tion systems: Hitest, which exemplifies the 
knowledge-based approach; Saturn, a 
bottom-up, hierarchical approach to test 
generation that exemplifies the use of 
abstraction; and MIT-TG, which includes 
aspects of both Hitest and Saturn and also 
employs a unique knowledge acquisition 
technique. 

Hitest 9 was developed to generate tests 
for sequential circuits. It uses a knowledge 
base to circumvent the complexity of test 
generation for these types of circuits. If we 
view test generation as a searching process, 
then the job of the knowledge base is to 
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bus 5 := 0 



Figure 6. Sample goal tree. 


constrain the search. The alternatives at 
each point in the search space form the 
branches of an AND/OR goal tree. 

Figure 6 shows an example of a test- 
generation goal tree. Nodes of the tree 
ANDed to a common parent must all be 
satisfied before the parent is satisfied, 
while nodes ORed to a common parent can 
independently satisfy the parent by their 
own solution. Figure 6 depicts the fact that 
bus 5 in Figure 4 can be set to the value 0 
if bus 1 and bus 4 are both set to value A. 
Bus 4 can be set to value A if both bus 2 
and bus 3 are set to value A . (Other alter¬ 
natives exist, 8 but are not shown in the 
figure.) 

Knowledge bases such as Hitest’s serve 
to prune this type of goal tree in two ways. 
First, nodes in the tree can be replaced, 
along with all their descendants, by a com¬ 
plete solution to the subproblem specified 
in the knowledge base. Second, sections of 
the tree can be pruned if the knowledge 
base specifies the impossibility of a solu¬ 
tion in these sections. For us to use such a 
knowledge base efficiently, it must be 
structured so that the information it con¬ 
tains is fairly general and applies in a large 
number of possible instances. Otherwise, 
searching the knowledge base becomes the 
computational bottleneck. 

Hitest’s knowledge base is mainly 
entered manually. It specifies the parti¬ 
tioning of the circuit into combinational 
and sequential parts and the manipulation 
of the sequential parts for test generation. 
Values stored in memory elements can 
often be easily set using primary input 
values that the circuit receives during nor¬ 
mal operation. While memory values 
might be time-consuming to generate for 
low-level test generation algorithms, 


strategies for deriving them are often quite 
obvious to human designers and so can be 
encoded in the knowledge base. In those 
cases where memory elements are not eas¬ 
ily set directly from the primary circuit 
inputs during normal operation, special 
test circuitry can be added to control them 
during a special test mode of operation. 
Information about control of memory ele¬ 
ments in the test mode can also be added 
to the knowledge base. 

The strategies for manipulating memory 
elements can be described at a fairly 
abstract level, which gives Hitest its status 
as a high-level test generator. In addition, 
Hitest has an important feature duplicated 
in a number of other high-level test gener¬ 
ators: precomputed (canned) tests for indi¬ 
vidual modules can be specified as test 
generation goals. The full set of tests for 
a module can be added to the knowledge 
base. Module inputs specified by the 
canned test are justified, and module out¬ 
puts are propagated in the usual way. 

Performance data for Hitest have not 
been published, but, since Hitest uses 
Podem to generate tests in the combina¬ 
tional parts of circuits, its worst case per¬ 
formance cannot be better than that of 
Podem. On the other hand, Hitest can 
generate tests for circuits using only a 
modest amount of human interaction 
(mainly through the knowledge base), 
which no strictly algorithmic approach 
might be able to handle within reasonable 
time/backtrack limits. 

Saturn is a test generator with a strong 
focus on design hierarchy. 10 The circuit 
model it uses has information both about 
the structural hierarchy and also about the 
rules of circuit behavior at the various 
levels of abstraction. For example, the 


adder in Figure lb is described structurally 
as composed of four full adder modules 
with appropriate connections. It can also 
be described in Saturn as a module per¬ 
forming the functional assignment S [0:3] 
:= .4 [0:3] + [0:3]. Similarly, the full 

adder modules are also described both 
behaviorally and in terms of their internal 
structure. Saturn will always attempt to 
propagate values through modules at the 
highest level of abstraction for which it has 
a model. 

The test generation algorithm used by 
Saturn resembles the D-algorithm. It oper¬ 
ates in bottom-up fashion by first gener¬ 
ating tests for faults on gates in the circuit. 
When testing a gate, values are propagated 
to the boundaries of the gate’s parent in 
the hierarchy, then abstracted to the 
behavioral level of the parent. 

As a demonstration of this bottom-up 
test generation philosophy, consider the 
four-bit adder of Figure 1 b repeated in Fig¬ 
ure 7. To generate a test for this circuit, 
Saturn will first generate a sequence of 
tests for all faults in one of the full adders, 
justifying internal signals only as far as the 
full adder inputs and propagating fault 
effects only as far as the full adder outputs. 
This test is then stored in a Saturn library 
for future use in testing full adders any¬ 
where in the circuit. Full adder tests can 
also be supplied in canned fashion, as in 
Hitest. Each test consists of a sequence of 
stimulus/response vector pairs. One such 
pair could be the partial test generated in 
the earlier example for the carry part of the 
full adder (see Figure 3). For this pair, the 
response part is S = 0 and C, + , = D, while 
the stimulus part is C, = 0, 4=0, and 
B = 0. 

Once a full adder test is available, 
Saturn will propagate its test response vec¬ 
tors one at a time to the outputs of the 
four-bit adder and justify its stimulus vec¬ 
tors to the inputs of the four-bit adder. The 
full adder test will be applied to each of the 
rest of the full adders in the four-bit adder 
in turn, and the new four-bit adder test will 
then be stored in Saturn’s test library. 

For purposes of illustration, suppose 
that a full adder test has been generated 
first for FA 0 and that this test includes the 
stimulus/response pair given above. The 
D signal can be propagated to the S output 
of FA i by assigning 0’s to FA ,’s t wo data 
inputs, A and B. The inputs to the remain¬ 
ing full adders can be assigned 0’s arbitrar¬ 
ily, resulting in the all-0 stimulus pattern 
A [0:3],fl [0:3] = 0000 and a response pat¬ 
tern of S[0:3] = 0£>00 for the four-bit 
adder. 


22 • 


COMPUTER 












Now suppose that a value generated 
during the testing of another module is 
incident at input fi[0:3] of the four-bit 
adder. To propagate this value, rather 
than resolving the hierarchy of the adder, 
Saturn will attempt to propagate the value 
to A [0:3] by making an explicit sensitizing 
assignment to >1 [0:3], say A [0:3] =0000. 
However, the general problem of deter¬ 
mining how to propagate values at a high 
level is difficult, and the methods used by 
Saturn have not been published. More¬ 
over, Saturn does not address the com¬ 
plexity problems created by general 
sequential circuits. 

We can expect significantly faster test 
generation for Saturn whenever a large 
number of tests can be reused. In addition, 
the more tests Saturn can propagate 
wholly at a high level, the better the per¬ 
formance once they have been abstracted. 
The performance measures reported by 
Singh 10 are in total computation time 
rather than module evaluations. The time 
values are unimpressive: 190 seconds to 
generate 13 tests for a four-bit adder (Fig¬ 
ure 1). Commercial (low-level) systems are 
at least an order of magnitude faster. 
Singh reported speedups of a factor of 3.5 
over test generation for circuits that were 
flattened. 10 

Like Saturn, the circuit model for MIT- 
TG is described hierarchically, and, like 
Hitest, it uses knowledge to constrain the 
search space. In contrast to Hitest, how¬ 
ever, this knowledge is not directly con¬ 
tributed by the user. Rather, it is derived 
from earlier simulations of the circuit, 
using a symbolic simulator. In practice, 
this earlier simulation step could be used 
for design verification purposes. 

Most test generation algorithms do not 
exploit “normal” circuit behavior, that is, 
behavior for which the circuit was 
designed. Instead, they explore the state 
space corresponding to behavior the cir¬ 
cuit is capable of exhibiting, which is con¬ 
siderably larger. MIT-TG was developed 
on the premise that most of the require¬ 
ments for propagation can be met at the 
high level by normal circuit behavior. As 
described by Shirley et al., 11 MIT-TG can 
only generate tests when normal behavior 
is discernible from the preliminary simu¬ 
lation step. It is therefore weaker in some 
respects than other approaches. On the 
Other hand, it is also considerably more 
computationally efficient and can be cou¬ 
pled with an expert system, also described 
by Shirley et al., 11 that counsels the 
designer to change the circuit in prescribed 
ways to make it more testable by MIT-TG. 



Figure 7. Four-bit adder. 


MIT-TG acquires test generation 
knowledge during symbolic simulation by 
recording module activity. Symbolic 
values assigned to module inputs and out¬ 
puts are recorded and linked to the 
behavior of other modules in the circuit 
and to the primary inputs and outputs. 
During test generation, symbolic proto¬ 
type test values are assigned to module 
inputs and outputs. To propagate and 
justify these symbolic values, MIT-TG 
relies on the data it recorded earlier. 
Finally, the symbolic values are replaced 
with sequences of canned test values 
required to test the module. 

We will again use the four-bit adder 
example of Figure 7 to illustrate this 
approach. In symbolic simulation, vari¬ 
ables and expressions as well as constant 
values are assigned to lines of the circuit. 
So, for example, if the variables X and Y 
are assigned to the inputs of the four-bit 
adder, the expression X+ Y is assigned to 
the output. If, during simulation, A is set 
to 0, then the output of the adder will be 
0 + Y = Y, thus effectively propagating 
the high-level Y value. The test generator 
can use this fact. If a prototype test value 
T is to be propagated from the input to 
which the Y is assigned to the output, T 
can be assigned to Y throughout the 
circuit. 

The performance results of MIT-TG 
have been reported only for one particu¬ 
lar circuit for an implementation on a 
Symbolics 3640. MIT-TG took six minutes 
to generate the prototype tests for a circuit 
with 16 higher level components equiva¬ 
lent to about 6,500 gates. 11 To produce 
the test pattern sets from the prototype 
tests requires some work, but the total time 
should compare favorably with current 
commercial systems. 


A s we have seen, the data pub¬ 
lished on the performance of 
high-level techniques relative to 
established low- (gate-) level techniques 
and to one another is sketchy. In most 
instances, no attempt was made to 
optimize performance, largely due to the 
experimental nature of current high-level 
test generation programs. In many cases, 
the primary program objective was to 
demonstrate the authors’ approach. Only 
Chandra and Patel 5 dealt extensively with 
the performance of the higher-level 
approach. Clearly, we need more detailed 
comparative data in this area. 

The algorithmic approaches tend to 
view test generation as a monolithic prob¬ 
lem that, if captured correctly in a prob¬ 
lem statement, can be solved by a single 
self-contained procedure. The approaches 
discussed above extend earlier test gener¬ 
ation algorithms such as the D-algorithm 
and Podem to use larger primitive ele¬ 
ments, thereby reducing circuit granular¬ 
ity. Each approach focuses on a particular 
technique and is effective for some classes 
of circuits, but not others. For example, 
Bhattacharya’s vector approach 2 is par¬ 
ticularly well suited to very regular circuits 
with multibit interconnections. It does not 
provide superior performance when used 
to generate tests for circuits that cannot be 
represented by high-level modules inter¬ 
connected by multibit buses. 

Although the high-level algorithms 
covered here have the potential of han¬ 
dling complex VLSI circuits, most have 
only been applied so far to relatively small 
cases. The heuristic test generation 
approaches, bowing to the complexity of 
the problem, tend to view test generation 
as a collection of interrelated problems, 
some of which have a known effective 
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solution and some of which do not. Prob¬ 
lems in the latter category are amenable to 
the knowledge-base approach described 
above. Hitest, for instance, solves the test 
generation problem for combinational 
parts of a circuit using Podem, but uses the 
knowledge base for sequential parts. MIT- 
TG uses a technique to generate tests 
quickly for parts of a circuit that can be 
tested using knowledge of simulation 
behavior and expects other parts of the cir¬ 
cuit to be modified by another procedure 
to make them more testable. 

The use of multiple techniques exempli¬ 
fied by the heuristic approaches is obvi¬ 
ously practical for VLSI circuits. We can 
therefore expect commercial systems to 
make use of multiple techniques. Hitest 
and several other commercial systems now 
use knowledge bases to augment test 
generation algorithms. Some of the cur¬ 
rent heuristic approaches have as their 
basis a philosophical principle (such as an 
attempt to emulate successful human 
behavior) whose effectiveness is hard to 
evaluate. The effectiveness of algorithmic 
approaches, on the other hand, can be 
directly evaluated. Future research into 
high-level test generation should concen¬ 
trate on devising effective algorithmic 
techniques for solving well-defined sub¬ 
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problems, such as sysfematic techniques 
for symbolic propagation through mod¬ 
ules, and also on efficient (heuristic) ways 
to combine these techniques. □ 
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Whistle 


A Workbench for Test Development 
of Library-Based Designs 


Raphael Renous,* Gabriel M. Silberman,** and Ilan Spillinger 
Technion 


T he techniques and software tools 
used for test generation and fault 
simulation of logic designs over 
the past few years have not kept pace with 
advances in very large scale integration 
technology. Problems with efficiency, 1 
capacity, and sometimes inadequacy of the 
fault models to the type of failures present 
in the new technologies 2 have caused con¬ 
cern for some time. 

Thus, for these tasks, recent research 
has focused on new approaches more 
suited to the requirements of VLSI tech¬ 
nology. Of particular interest are 
approaches that rely on a hierarchical rep¬ 
resentation of the design (such as in Rogers 
and Abraham 3 ) because they agree with 
current trends for designing VLSI circuits. 

Moving test generation and fault simu¬ 
lation away from the gate level to a higher 
level of abstraction has the potential for 
supplying the answers to concerns about 
efficiency, capacity, and fault model ade¬ 
quacy for VLSI designs. However, in 
general, a major problem in making this 
transition resides in the character of the 
results produced by the high-level tool 
and, in particular, in how those results are 
translated to the more familiar measure¬ 
ments of fault coverage at the gate level; 
that is, the results obtained by performing 
high-level fault simulation must be 
expressed in terms of fault coverage for the 
devices and signals that are familiar to the 
designer. Several efforts in this direction 
have been reported in the literature (for a 
survey, see Tomas and Shen 4 ), but none 
has produced consistently accurate results. 


Based on the 
Difference Fault 
Model approach 
to fault simulation 
and test generation, 
Whistle supports the 
development of 
test patterns for 
library-based VLSI 
designs. 


In this article, we adopt the Difference 
Fault Model (DFM) approach 5 to the 
simulation of high-level designs and build 
a complete environment for test genera¬ 
tion and fault simulation of designs 
expressed in a hardware description lan¬ 
guage (HDL), such as VHDL . 6 This envi¬ 
ronment, called Whistle (Workbench for 
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High-Level Simulation and Test- 
Development), consists of a set of pro¬ 
grams that supports a library-based 7 
design style. 

We distinguish three groups among the 
tools Whistle provides. 

• First, we have tools for analyzing 
blocks as they are added to the design 
library. 

• Second, a high-level fault simulator 
can produce results that can be 
mapped to fault coverage at a lower 
(such as, gate) level. 

• Third, another group of tools pro¬ 
vides support for high-level auto¬ 
matic test pattern generation in the 
form of a list of blocks with low fault 
coverage and diverse statistics mea¬ 
sured during fault simulation. 

At this point, we should clarify that we 
see a high-level design as the interconnec¬ 
tion of functional blocks that belong to a 
given design library. In this context, “low 
level” refers to whatever description (such 
as gates and transistors) is used for the 
blocks in the library. Furthermore, since 
the DFM approach is independent of the 
fault model adopted for the low level (such 
as stuck-at, stuck-open, and bridges), our 
tools can support a variety of such models. 

Whistle runs under IBM’s VM/CMS 
and was designed to automate as many 
facets of the test generation and fault 
simulation tasks as possible. When that is 
not possible. Whistle provides a set of 
interactive menu screens designed for sim¬ 
plicity. This will be illustrated in the next 
section where we present an overview of 
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Figure 1. The tools of Whistle. 


the tools in Whistle, emphasizing those 
used for analyzing library blocks. The sec¬ 
tion entitled “Code generation for fault 
simulation” will include a description of 
the integrated control logic for driving the 
simulation and performing fault injection. 
Analysis of the results obtained during 
fault simulation and their use in biased- 
random test pattern generation 8 
(BRTPG) will be the focus of the “Results 
analysis” section. The “Results and per¬ 
formance” section will cover Whistle’s 
accuracy as illustrated by comparison to 
direct fault simulation at the gate level on 
a number of combinatorial designs. 


Overview of Whistle 


In this section, we describe the tools in 
Whistle, with special emphasis on the tools 
used to analyze each block in the design 
library. To better follow this overview, 
keep in mind our objective of producing 
information in terms familiar to the 
designer, that is, keyed to the design imple¬ 
mentation while performing most of the 
tasks using some higher-level design 
description. (We will use the term “func¬ 
tional” to indicate this higher level of 
abstraction.) 


As indicated in Figure 1, which shows 
the different tools of Whistle and their 
relationships, we distinguish three tasks 
for our workbench. The first task, labeled 
“Block analysis” in the figure, is to gener¬ 
ate a functional fault model for each block 
in the design library. This fault model is 
the foundation for Whistle and supplies 
three main pieces of information, namely 

(1) the functional faults (F-faults) 
assumed to be the manifestations of 
possible defects or failures, that is, 
implementation faults (I-faults), in 
the circuit, 

(2) the conditions (input) under which 
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each such F-fault manifests itself, 
and 

(3) the measurements that should be 
made during the course of high- 
level (F-fault) simulation to deter¬ 
mine what percentage of all I-faults 
were detected by a given set of test 
patterns. 

The program used in the analysis of 
library blocks is called Dmat (for Differ¬ 
ence Matrix). As input, this program takes 
the description of how a block is imple¬ 
mented and the assumed implementation 
fault model and produces the DFM tables 
(see Figure 1) as its output. These tables 
represent the raw data from which all the 
functional fault model information is 
extracted. In our prototype, we use gate- 
level descriptions for the library blocks and 
a single-stuck-at implementation fault 
model (that is, at any given time, a single 
line in the circuit is assumed to have a per¬ 
manent 0 or permanent 1 value). 

In addition to Dmat, two other pro¬ 
grams complete the first set of tools in 
Whistle. These are Injent (Injection 
Entropy) and Detent (Detection Entropy). 
Injent deals with F-fault injection (the pro¬ 
cess of changing the behavior of the logic 
being simulated, to reflect the presence of 
an F-fault), and Detent deals with F-fault 
detection (recording the fact that the effect 
of an F-fault propagated to an output or 
some other observable point in the circuit). 
Performing accurate fault injection (for 
either F-faults or I-faults) is critical, and 
faults should be injected only if the appro¬ 
priate input conditions allow it to manifest 
itself. If a fault is injected under the wrong 
input conditions and its effect propagates 
to an output, we can flag this fault as being 
detected by the test pattern being used, 
whereas in reality, it has no chance of even 
manifesting itself. (This “optimism” is 
what test developers fear the most, since 
claiming that a fault is not present in a cir¬ 
cuit, based on the fact that the above test 
pattern did not cause an erroneous output, 
can lead to labeling a circuit as fault-free 
when in fact it contains a fault.) 

Both Injent and Detent are interactive 
programs that use the DFM tables as well 
as receive input from the user. Injent 
produces the information needed to per¬ 
form accurate fault injection during F- 
fault simulation, while Detent determines 
the phenomena to be recorded during this 
simulation (that is, the number of times 
and the conditions under which an F-fault 
is injected and how many times it was 
detected) and supplies the necessary data 
for deriving the I-fault coverage from 


these measurements. 

A block must be analyzed only once, at 
the time it is added into the design library. 
Repeating the analysis is only necessary if 
a block is modified or if a different fault 
model is deemed necessary. Therefore, the 
block analysis tools are used by a relatively 
small population of test engineers in 
charge of creating and maintaining design 
libraries, while the rest of the tools in 
Whistle are intended for the average 
designer. The next section details the block 
analysis process. 

The second task for Whistle is to supply 
the tools to perform fault simulation of a 
design. The approach chosen for this task 
is to directly compile the design into 
executable PL/1 code, using the Hifast 
(High-Level Fault Simulator) compiler. 
This code incorporates all the necessary 
logic for performing F-fault injection and 
is instrumented to count the number of 
injections and detections for each F-fault. 
Test patterns to be used as input to the 
fault simulator can be prepared off-line or 
generated on-line using some pseudoran¬ 
dom technique. Whistle supports both 
these approaches, as well as providing the 
tools for generating biased-random pat¬ 
terns (nonuniformly distributed random 
patterns). The “Code generation for fault 
simulation” section further elaborates on 
the fault simulation process. 

Measurements gathered during fault 
simulation are kept in terms of the high- 
level F-faults, whereas the user is usually 
interested in the fault coverage for the low- 
level I-faults. The task of translating 
between these two levels falls upon the pro¬ 
gram Cover (see Figure 1). This tool takes 
as input the results from F-fault simulation 
and uses data generated by the block anal¬ 
ysis tools to produce an estimate of the I- 
fault coverage for a given set of input pat¬ 
terns. Since this estimate bears a direct 
relation to specific I-faults, it is easy to 
identify those I-faults that have a high 
probability of remaining undetected and 
thus should be the targets of further test- 
generation efforts. (This particular feature 
of the DFM approach to fault coverage 
estimation, that is, supplying detection 
probabilities for each individual I-fault, 
sets it apart from other probabilistic 
methods, such as fault sampling.) 

Support for test generation is provided 
in the form of the tool BRTPG. This tool 
targets certain F-faults as candidates for 
detection by algorithmically generated 
biased-random patterns. The chosen F- 
faults are those related to I-faults with low 
detection probability, as determined by 


Cover. Support for test generation is 
detailed in the “Results analysis” section. 

Block analysis. As stated above, the 
objective of block analysis is to obtain the 
functional fault model for a given library 
block. Derivation of the functional fault 
model is done according to the DFM 
approach 5 as explained below. 

Let us consider a single block in the 
design library and examine the effect of I- 
faults (assumed defects or failures) on its 
behavior. Assume that for some input vec¬ 
tor v, the output from this block is the set 
of n bits b (h b u ... ,b n ,, representing the 
number g = b 0 x 2° + b\ x 2 1 + ... + 
6„_ 1 x2"~ l . The effect of an I-fault on 
the number g, if present for input v, is to 
cause the output to be w instead of g. We 
can express the functional effect of this I- 
fault under input v as the arithmetic differ¬ 
ence d = w - g. This difference d might 
be common to other pairings of I-faults 
and input vectors. Therefore, we assign F- 
faults to a given block to match all the 
values that d can attain. Thus, the set of all 
possible F-faults (the fault model) 
associated with a block is given by 

FF = U d u , 

where djj is the difference associated with 
the pair “input vector v, and I-faulty.” 

Example 1. To illustrate the process for 
determining the DFM for a functional 
block type, let us consider the decoder 
shown in Figure 2. If we assume a single- 
stuck-at implementation fault model, the 
list of I-faults for this block includes 24 
faults, as listed in Table 1. (Actually, there 
are more than 24 I-faults in this block, but 
some of them belong to the same fault 
equivalence class as one of the faults in the 
list. Since faults in the same equivalence 
class are detected by the same test patterns, 
it is only necessary to keep one fault per 
class as a representative. For example, I- 
fault 17, “output line of gate 3 stuck at 0,” 
represents the fault equivalence class that 
also includes the faults “right input to gate 
3 stuck at 0” and ‘ ‘left input to gate 3 stuck 
at 0.”) Table 2 shows the differences djj 
obtained by simulating all I-faults, using 
all (four) possible input combinations. By 
examining this table (we refer to it as the 
Difference or D-matrix ), we see that the set 
of all possible F-faults in this case is given 
by FF = {±1, ±2, ±3, ±4, ±6, ±8}. 

Block analysis begins with the program 
Dmat, which takes as input the implemen¬ 
tation description of a block (in our pro¬ 
totype we use a gate-level representation) 


April 1989 


29 






Figure 2. A 2-to-4 decoder. 


Table 1. List of I-faults for the decoder in Figure 2. 


I-fault Number 

Fault Description 

1 

right input to gate 3 stuck at 1 

2 

left input to gate 3 stuck at 1 

3 

right input to gate 4 stuck at 1 

4 

left input to gate 4 stuck at 1 

5 

right input to gate 5 stuck at 1 

6 

left input to gate 5 stuck at 1 

7 

right input to gate 6 stuck at 1 

8 

left input to gate 6 stuck at 1 

9 

input line Co stuck at 0 

10 

input line C 0 stuck at 1 

11 

input line C\ stuck at 0 

12 

input line C, stuck at 1 

13 

output line of gate 1 stuck at 0 

14 

output line of gate 1 stuck at 1 

15 

output line of gate 2 stuck at 0 

16 

output line of gate 2 stuck at 1 

17 

output line of gate 3 stuck at 0 

18 

output line of gate 3 stuck at 1 

19 

output line of gate 4 stuck at 0 

20 

output line of gate 4 stuck at 1 

21 

output line of gate 5 stuck at 0 

22 

output line of gate 5 stuck at 1 

23 

output line of gate 6 stuck at 0 

24 

output line of gate 6 stuck at 1 


and the given implementation fault model 
(we use single-stuck-at) and builds the D- 
matrix for the block (as in Figure 1). Other 
implementations (for example, transistor- 
level) as well as fault models (for example, 
bridges, stuck-open) are possible with the 
DFM approach. All that is needed to sup¬ 
port them is an appropriate process for 
deriving the appropriate D-matrix. 
(Blocks with either fault-free or fault- 
induced sequential behavior are handled 
by adding pseudo-inputs and pseudo¬ 
outputs to the block for each memory-like 
element therein.) The F-faults associated 
with this block are then extracted from the 
D-matrix in a straightforward fashion. 

Next, we will discuss the other two com¬ 
ponents of the functional fault model, 
namely the data for the fault injection pro¬ 
cess and what measurements should be 
performed during simulation. In principle, 
the information we need is contained in the 
D-matrix (as produced by Dmat) for each 
block, but keeping the full matrix for large 
blocks might be impractical in terms of 
both storage and performance. Therefore, 
we look for ways to extract and compress 
the relevant information from the D- 
matrix without compromising the 
accuracy of the results obtained (for fur¬ 
ther details, see Silberman and 
Spillinger 9 ). In Whistle, the user is given 
the power to make the trade-off between 
an increase in accuracy and the associated 
space/time penalties, during the analysis 
of each library block. 

The data for fault injection and fault 
coverage calculations, as produced by 
Dmat for each block in the library, consists 
of the following tables: 

(1) For every output bit s of the block, 
two tables are created 

(a) V 9 —the off-set of s, a list of 
all input vectors for which bit 
s of the (fault-free) output has 
the value 0; and 

(b) V]—the on-set of s, the list of 
all input vectors for which the 
bit s of the (fault-free) output 
has the value 1. 


Table 2. Difference Matrix for the decoder in Figure 2. 


C, C 0 g 1 2 3 4 

0 0 1 0 0 2 0 

0 12 10 0 0 
1 0 4 0 1 0 0 

1 1 8 0 0 0 2 


5 6 7 
0 4 0 
0 0 0 
0 0 8 
4 0 0 


8 9 10 11 12 13 

00103-1 
8-1 0060 
0 0 4 -3 0 -4 
0 -4 0 -6 0 0 


14 15 
0 -1 
1 -2 
0 0 
4 0 


16 17 
0 -1 
0 0 
1 0 
2 0 


18 19 20 21 22 23 24 

0 0 2 0 4 0 8 

1 -2 0 0 4 0 8 

1 0 2 -4 0 0 8 

1 0 2 0 4 -8 0 
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(2) For each functional fault value 

ffv 6 FF of the block 

(a) for each I-fault,, SF //vJ , a list 
of the inputs to the block that 
“excite” this I-fault and 
cause the appearance of F- 
fault/fv at the block’s output. 

(b) MBD //V , a list of inputs that 
cause a multiple bit distortion 
on the block’s output. 

(c) SBDjyv, a list of inputs that 
cause a single bit distortion on 
the block’s output, only for 
the case where ffv is of the 
form ± 2 s . 

For example, for the Decoder of Exam¬ 
ple 1, = {0,1,3}, V} = {2}, SBD 4 = 

V2 = {0,1,3}, MBD 3 = {0}, andSF 422 = 
{0,1,3}. 

The sets (lists) V?, Vj, SBD //v and 
MBDjyv are needed for the fault injection 
process, while the SFare used during 
estimation of the implementation fault 
coverage (see Silberman and Spillinger 5 ' 9 ). 

Example 2. To further illustrate the 
above sets, we now introduce FA2, a two- 
bit full adder (see Figure 3). This example 
will be used throughout the remainder of 
the article to illustrate several features of 
Whistle. 

Running Dmat on FA2 yields the set FF 
= {-4,-2, - 1,1,2,4} of functional 
faults. The sets needed for fault injection 
for each ffv e FF are given by 
MBD_ 4 = <D 

SBD_ 4 = {11,13,14,15,19,21,22,23, 
24,25,26,27,28,29,30,31} 
MBD 2 = {11,13,14,15,19,21,22,23} 
SBD_ 2 = {3,5,6,7,8,9,10,12,16,17, 
18,20,27,29,30,31} 

MBD_, = <D 

SBD_, = {1,2,4,7,9,10,12,15,17,18, 
20,23,25,26,28,31} 

MBD, = <t> 

SBD, = {0,3,5,6,8,11,13,14,16,19, 
21,22,24,27,29,30} 

MBD 2 = {8,9,10,12,16,17,18,20} 
SBD 2 = {0,1,2,4,11,13,14,15,19,21, 
22,23,24,25,26,28} 

MBD 4 = 4) 

SBD 4 = {0,1,2,3,4,5,6,7,8,9,10,12, 
16,17,18,20} 

V2 = SBD 4 V\ = SBD_ 4 
V? = SBD 2 V{ = SBD_ 2 
Vo = SBDj Vo = SBD_, 

Notice that for the FA2 case, every ffv 
is of the form ±2 S (0 < s < 2), with only 
the F-faults ffv = ±2 having each MBD^ 
it «D. 


As mentioned above, we aim to com¬ 
press the information contained in the 
above tables (as derived from the D- 
matrix) without sacrificing accuracy in the 
process. The next subsections will show 
our approach to solving this problem, 
building on the work of Silberman and 
Spillinger 9 and implemented by the pair 
of programs, Injent, for fault injection, 
and Detent, for fault coverage evaluation 
(see Figure 1). 

Characterizing sets of vectors. In 

general, there is no known automatic 
procedure for producing a compact 
characterization of a set of vectors, other 
than trial and error. However, as shown in 
Silberman and Spillinger, 9 it is possible to 
evaluate how good a characterization is 
without having to perform extensive 
experiments and/or calculations. Thus, 
Whistle provides an interactive environ¬ 
ment through which the user can select a 
characterization for a set of vectors and 
obtain a measure of its “quality” 
(accuracy). (The selection process is left to 


the user, who has better knowledge of the 
block’s function and might have a better 
intuition as to what would work best. 
Online help, in the form of a few standard 
characterizations, is also available in 
Whistle.) This measure of quality is given 
by an evaluation function based on 
entropy measurements. 10 This evaluation 
function yields a value inversely propor¬ 
tional to the accuracy of the set characteri¬ 
zation and attains its optimum (minimum) 
value of zero for the characterization that 
maintains complete accuracy. 

The two programs dealing with evalua¬ 
tion functions, namely Injent and Detent, 
present the same user interface and differ 
only in their respective evaluation func¬ 
tions. In this subsection, we will introduce 
the common interface, while the following 
subsection will briefly deal with the evalu¬ 
ation function for each program. 

The common user interface is shown in 
Figure 4. In it, we distinguish the top, mid¬ 
dle and bottom areas of the screen. The 
top area shows the block’s name (which is 
a parameter), and characteristics from its 
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-ENTROPY OF BLOCK FA2- 

Number of Input Bits: 5 (10 II ...) 

Number of Output Bits: 3 (OO Ol ...) 

Number of Functional Faults: 6 

For which Fault: (All, List of Numbers) 

Number of Counters: 2 



PF1 - Help PF2 - Calculate PF3 - Quit PF4 - Save 


Figure 4. User interface for Injent and Detent. 


library description (number of input and 
output bits), and data supplied by Dmat 
(number of functional faults). Immedi¬ 
ately following this information are two 
fields to be filled in by the user (they are 
highlighted on the screen), that is, which 
F-fault(s) the user wants to process, and a 
limit to the number of counters to be 
updated (during fault simulation) for this 
fault (this is relevant for Detent, while 
Injent uses the default of 2). The middle 
area of the screen is allocated to the 
description of the characterization that the 
user wants to evaluate, while the bottom 
part shows program function (PF) key 
definitions and provides means to input 
CMS commands. All messages (errors and 
other information) produced by the pro¬ 
grams also appear in the bottom area of 
the screen. 

Characterization of a set of vectors is 
described by the user in terms of the 
characterization function, whose argu¬ 
ments are (some of) the input and/or out¬ 
put bits for the block being studied. 
Ideally, when a characterization function 
for a set of vectors S is applied to a vector 
v, it yields a true result if veS and false 
otherwise. The user expresses this function 
in PL/Ent (Programming Lan¬ 


guage/Entropy), a simple programming 
language whose grammar is trivial but 
allows for a wide variety of functions. In 
PL/Ent, variable names are just one let¬ 
ter long (maximum is 26 variables), and 
each such variable represents a string of 
bits. Individual bits in the string can be 
referred to by the name of the variable and 
the position of the bit next to it (for exam¬ 
ple, G1, 70), with bit 0 being the most sig¬ 
nificant bit. No explicit concatenation 
operator exists, but two variables (or bits) 
written next to one another (for example, 
TS2) are implicitly translated to the con¬ 
catenation of the two variables. 

There are two predefined variables, I 
and O, which represent the input and out¬ 
put bits of the block, respectively. Their 
lengths are shown in the top portion of the 
screen (see Figure 4). Separation between 
two statements in a program is done either 
by using a semicolon (;) or by a new line. 
The full grammar of PL/Ent is given in the 
sidebar. Below are two examples of 
PL/Ent programs as they would be 
entered by the user. 

Example 3. Let us consider the two-bit 
full adder FA2 of Figure 3, which has five 
input bits (7 0 7, ... / 4 ) and three output 


bits (O 0 • • • 0 2 ). The program, return 1113 
xor 0214, evaluates the characterization 
function / / 3 ® 0 2 h- 

Example 4. For the same FA2 block as 
in Example 3, a more sophisticated pro¬ 
gram for a characterization function is 
given by 

var S(2), X 

S = 12 + 13 + 14; X= 10 xor II 

if SOX = ‘01’ then return 1 
else return 0 

fi 

When the user terminates to enter his 
PL/Ent program, depressing the PF-2 key 
causes its translation into a PL/I function. 
This function is compiled and linked to a 
program that evaluates the quality of the 
characterization function, which is then 
run and the result displayed to the user. 
(The meaning of this result for Injent and 
Detent is explained in the following sub¬ 
section.) If the result obtained does not 
please the user, he or she can try modify¬ 
ing the characterization function or try 
using a completely different one until satis¬ 
fied. When this occurs, the PF-4 key will 
cause association of the given characteri¬ 
zation function with the library block (and 
F-fault) being processed. 

The PF -1 (Help) key gives the user a list 
of simple characterization functions and 
can guide him or her in the (initial) choice 
of a good function. In the following sub¬ 
section, we will examine the evaluation 
functions for Injent and Detent. 

Evaluation functions for Injent and 
Detent. Following the strategy for fault 
injection proposed in Silberman and 
Spillinger 9 and described briefly in the 
“Code generation for fault simulation” 
section below, we need for each ffv e FF, 
characterization functions for the sets 
SBD //V and MBDy /v . (The sets V? and Vj, 
as produced by Dmat, serve as a first try 
for characterization functions. This case 
is illustrated in Example 2, for all the 
SBD //V sets.) 

Let us assume that we want to find a 
characterization function/for the vectors 
in the set VOI (vectors of interest) that best 
distinguishes them from among the vectors 
in the set APV (all possible vectors). 
Clearly, VOI C APV, and we are looking 
for a function that yields values for vectors 
in VOI that differ from those given when 
the function is applied to vectors in the set 
APV-VOL Let us define VOI' (APV') 
as the (sub)set of vectors from VOI (APV) 
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PL/Ent grammar 


specified by truth-table, on the var¬ 
iables varl, varl. 

Declaration statement 

VAR variable list 

Every variable (except variables / 

Arithmetic operators 



and O) must be declared. If no 
length is specified, the default is 

1. The declaration statement may 
appear anywhere in the program, 
even after the use of the variables 
declared in it. 

Return statement 

RETURN expression 

The value of the expression will be 
returned by the function. Notice 
that when the program reaches a 
return statement, the rest of the 
program is not evaluated. 

Constant 

A number between quotes is inter¬ 
preted as a binary string, 
otherwise as a decimal number. 

If statement 

IF condition THEN statements) FI 

IF condition THEN statement(s) 

ELSE statement(s) FI 

Every If statement must be termi¬ 

Unary operators 

NOT, - 


nated by the keyword FI. This 
allows for a block of statements to 

Boolean operators 

XOR,OR, AND 

BOOL (varl, var2, truth-table) 

BOOL returns a bit string that is 
the result of a Boolean operation, 


be used in either the then-part or 
the else-part, without using a block 
“bracketing” structure (for exam¬ 
ple, Begin ... End in Pascal). 


for which / yields a value of and P = 
|VOI'| 4- |APV'|. 

Ideally, we would like to have either P 
= 0, which means that no vector in VOI 
yields a value of i when used as the argu¬ 
ment to the characterization function, or 
P = 1, which implies that all vectors that 
yield a value of i for the characterization 
function belong to VOI. Therefore, Injent 
measures the quality of a characterization 
function by checking how close it is to this 
ideal, using an entropy-based 10 evaluation 
function. In choosing a good characteri¬ 
zation function, we must also consider the 
size of its domain and the efficiency of its 
evaluation, since both these factors affect 
simulation performance. 

In principle, the set APV contains all 
2” possible input vectors for a block with 
m input bits. But, it is sometimes easy, and 
always advantageous, to restrict APV to 
a smaller set using a simple check. For 
example, an F-fault that causes a single-bit 
distortion with a positive difference (such 
as + 2 s ) cannot possibly exist in conjunc¬ 
tion with an input vector I that yields a 
value of 1 for bit s (that is /eV]). The 
advantage in restricting the size of APV is 
that there is a better chance that a good 
characterization function will be simpler. 

Let us now consider the VOI sets we 
want to characterize, that is SBD //V and 
MBD //V . First, when ffv = + 2 s (- 2 1 ), we 
have that APV = V? (V]) for VOI = 
SBD //V , and APV = V] (V?) for VOI = 


MBD//V- The only other type of VOI we 
must consider are those MBD^ sets with 
ffv =£ ±2 S , for which we cannot restrict 
APV, and thus |APV| = 2'". 


Example 5. Let us consider the FA2 
block of Example 2, together with the 
characterization function given in Exam¬ 
ple 4. Applying this function to the set 
MBD2 (for which APV = V|), we have 
that 


p o 


|VQ1°1 

|APV°| 

_M_ 

|{3,5,6,7,27,29,30,31 }| 


and 

P 


|{8,9,10,12,16,17,18,20}| 
|{8,9,10,12,16,17,18,20}| 


We see that P‘ e {0,1}, / = 1,2, and thus 
this characterization function maintains 
full accuracy. 

Whereas Injent addresses the question 
for which vectors appearing at the input to 
a block a certain F-fault must be injected, 
Detent must deal with vectors that caused 
detection of a given F-fault. In this case, 
we are interested in knowing which I- 
fault(s) can be covered by such a detection, 
and thus we want to characterize input vec¬ 
tors in such a way as to distinguish among 


I-faults that correspond to the same F- 
fault. Thus, the sets to be characterized in 
this case are the SF^vj- Since we now have 
a number of sets (one for each of the I- 
faults in question) for each ffv and they all 
must be handled by the same characteriza¬ 
tion function, the previous evaluation 
function cannot be used. But, a similar 
approach, using another entropy-based 
measure, is possible in this case as well. 

For the sake of brevity, we do not 
develop here the evaluation functions used 
by Injent (E, njent ) and Detent (E Dete „,). 
Both evaluation functions yield a value of 
zero when applied to characterization 
functions that maintain full accuracy. In 
addition, as we will see in the section titled 
“Results and performance,” the closer 
Einjem and E De!ent are to zero, the. more 
accurate are the fault coverage estimates 
given by Cover. (The formulas for both 
Einjent and E Deten t are given in the sidebar 
titled “Evaluation functions.”) 

The next section describes the genera¬ 
tion of code for the simulation of the F- 
faults in the design. 

Code generation for 
fault simulation 

Although the block analysis phase 
involves a large amount of work, since it 
must handle each F-fault within every 
block in the design library, this phase is 
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Evaluation functions 

The quality of a characterization function f, as measured by 
Injent, is given by the evaluation function 

E lnjent<0=- £ [P' log 2 P' + (1-P') log 2 (1-P')] 


tion of ffv, and that of l-fault /. Therefore, we define for each / 
= 1... r (r is the number of l-faults in the block for which SF 
*<t>) the auxiliary functions 

6/(0 = - £ [P' log 2 P' + (1 - P') log 2 (1 - P')] 


where k is the size of the domain of f, P' = | VOl' | -=- | APV' f, 
and VOl' (APV') is the subset of vectors from VOl (APV) for 
which f yields a value of /. 

Detent requires a slightly more complex evaluation function 
since, for each ffv , the same characterization function must 
deal with all the (non-empty) SF„ fiJ sets. Recall that these sets 
relate the need to inject a given F-fault ffv, to the manifesta¬ 
tion of l-fault/, and thus represent the link between the detec¬ 


where k is the size of the domain of f, and P' = | | + 

| A',,„ | with SF' I/VJ (A'„ v ) being the subset of vectors from SF„ Vi/ 
(SBD,,„ U MBD,,„) for which / yields a value of i. 

The evaluation function for Detent is then given by 


E Detent(0 = 



done just once, when the library is created. 
Clearly, blocks being added to the library 
or changes done to their low-level imple¬ 
mentation and/or fault model require that 
the analysis be repeated. But, once a design 
library becomes stable, these actions are 
few and far between. On the other hand, 
the code generation and fault simulation 
phase (see Figure 1) is repeated countless 
times for all the designs based on the same 
library. This section describes the tools in 
Whistle that handle these tasks. 

The generation of code to represent the 
design to be simulated relies on syntax- 


directed translation techniques. 9 This 
process is implemented by the Hifast com¬ 
piler, which analyzes the HDL description 
of the design and generates PL/1 code 
according to the information produced by 
the block analysis phase. Actual simula¬ 
tion proceeds after the PL/1 code is com¬ 
piled and linked to some service routines. 

We chose PL/1 as the object code for 
Hifast for rapid prototyping. The result¬ 
ing code is highly readable, and its cor¬ 
respondence to the original design is quite 
apparent. Nevertheless, as we shall see 
below, we restrict the PL/1 code to follow 


DCL (AO,A1 ,BO,B 1 ,CO,SO,S 1 ,C1) BIT; 
^INCLUDE FA2; 


BLOCK 1: 

RES = FA2 (CO,AO,BO,A1,B1); 

50 = SUBSTR (RES,1,1); 

51 = SUBSTR (RES,2,1); 

Cl = SUBSTR (RES,3,1); 

GOTO BLOCK(2); 

BLOCK IF: 

GOOD = RES; 

INP = CO || AO || BO || A1 || Bl; 
TYPE = 1; 

CALL FAULT-INJECT; 

50 = SUBSTR(OUTP ,1,1); 

51 = SUBSTR(OUTP,2,l); 

Cl = SUBSTR(OUTP,3,l); 

BL0CK2: 

GOTO RETURN-TO-CONTROL; 


/* include the good behavior of FA2 */ 
/* from the library */ 

/'"fault-free output ( g) */ 

/* individual output bits */ 

/* overriden by global control */ 

/* faulty behavior */ 

/* save the fault-free output */ 

/ * the input vector */ 

/* for the FA2 block */ 

/* fault injection procedure */ 

/* faulty output bits */ 


/*endof design */ 


Figure 5. Sample PL/1 code generated by Hifast. 


a style that facilitates its replacement by 
performance-oriented machine language 
code for a production version of Whistle. 

Code generated by Hifast consists of 
three parts, 

• the declaration part that corresponds 
to the definition of the facilities (that 
is, signals, latches, etc.) in the design, 

• the block execution part in which 
each block’s representation includes 
both its fault-free and faulty 
behaviors, and 

• the global control part for activating 
the injection of faults during simula¬ 
tion, gathering of the fault injec¬ 
tion/detection data, and supervising 
overall execution of the code. 

The first part is a straightforward map¬ 
ping of the facilities declared in the HDL 
to variables in PL/1, and we will not 
extend its description here. 

The block execution part has the general 
structure shown below: 

Block 1: 

Good Output Computation 
Goto Block (2) 

Blocklf: 

Fault Injection Procedure of Block 1 

Block2: 

Good Output Computation 
Goto Block(3) 

Block2f: 

Fault Injection Procedure of Block2 

Block3: 


We can see that, for each block in the 
design, Hifast generates a two-part seman¬ 
tic routine, consisting of 
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(1) computation of the fault-free out¬ 
put ( g ) from the block in question; 
and 

(2) deciding which fault(s) (if any) are 
to be injected for this block 
(depending on its current input) and 
adding the appropriate difference(s) 
d( = ffv) to the good output g (see 
the “Overview of Whistle” 
section). 

Each label variable Block(z) is set equal 
to Block/ for the fault-free execution of the 
design, which thus proceeds in an oblivi¬ 
ous fashion. In this manner, the control 
flow of the original HDL description is 
maintained. When exercising the code with 
faults, the global control logic changes the 
values in the label variables (for example, 
Block(2) is set to Block 1/when faults are 
injected into Blockl). Also, the overall 
control flow assumes a more event-driven 
flavor during fault simulation, for reasons 
of efficiency. 

Example 6. Assume that the following 
statements appear in a design (we use 
VHDL 6 only as an example): 

component FA2 is 

port (CIN,X0,Y0,X1,Y1 : in BIT; 
ZO,Z1,COUT : out BIT); 

end component; 

signal AO,Al,BO,Bl,CO,SO,SI,Cl: 

BIT; 

FI : FA2 port map ( 

CIN = > CO, XO = > AO, 

YO => BO, XI => Al, 

Y1 = > Bl, ZO = > SO, 

Z1 => Sl.COUT => Cl); 


The PL/1 code generated by Hifast in this 
case is shown in Figure 5. 

Notice that the code generated is simple 
and “flat” in the sense that the use of 
subroutines and do-loops is minimal and 
the use of goto is frequent. As mentioned 
above, this fits our decision to make the 
code similar to what we would do at the 
machine-language level (for example, 
notice that no parameters are passed to the 
fault injection procedure; instead we use 
the global variables GOOD, INP, TYPE 
and OUTP). A by-product of this style is 
the freedom given to the PL/1 compiler to 
optimize the code. 

Next, we look at our implementation of 
the fault injection procedure FAULT- 
INJECT. 

FAULT-INJECT—The fault-injection 
procedure. FAULT-INJECT is a general 


procedure for the injection of faults. It 
performs those tasks that are common to 
all types of blocks, then calls type-specific 
procedures that handle each block type 
according to the characteristics determined 
by Injent. FAULT-INJECT uses three 
global variables as input parameters: 
GOOD —the good output (g ) from the 
block; INP —the current input to the 
block; and TYPE— the block’s type. It 
returns in the global variable OUTP, the 
faulty output (w) according to the fault 
model of that block. For some values of 
the input, several faults might need to be 
injected. In this case an array is used to 
hold all these faults, and successive calls to 
FAULT-INJECT will produce the faults 
one after the other. Also, FAULT- 
INJECT saves the state of the design var¬ 
iables so that the fault-free simulation does 
not have to be repeated between successive 
faults. 

Figure 6 shows a (pseudocode) general 
template for building a type-specific 
procedure according to the information 
supplied by Injent. Recall that the objec¬ 
tive is to decide which, if any, functional 
fault value(s) (the ffvs) must be added to 
the good output g for the present input to 
the block. Notice the distinction being 
made between the sets SBDjy v and 
MBD// V . This is done since in a large num¬ 
ber of cases where ffv = +2* (-2 s ), we 
have that SBDr fv = V* where be {0,1}. 
(Recall that vf denotes the set of inputs 
for which the fault-free output bit s has the 
value b.) In this particular case, the value 
of bit s signals whether ffv must be injected 
and, if so, bit s is simply inverted. Further¬ 
more, when the pair of F-faults ±2 S fit the 



above characteristics (as in the case of sim¬ 
ple Boolean gates), we can do away with 
the checking of bit s and immediately 
invert it. 

In the general case, we must test for 
inclusion of the input INP in one (or both) 
of the sets SBD //v and MBD //V ,. This is 
done by computing the characterization 
function defined using Injent, with INP 
and GOOD supplying the arguments. 

Example 7. The fault injection proce¬ 
dure for the FA2 block is shown in Figure 
7. Notice that we take advantage of those 
cases (for example, ffv = ±4) in which the 
characterization function is trivial and per¬ 
form bit inversions as explained above. 

The global control. The logic that con¬ 
trols code execution during fault-free and 
faulty design simulation has the overall 
structure shown below. 

• While there are input patterns 

• Read the next input pattern 

• Simulate the fault-free machine 

• For each block i executed during 
the fault free simulation 

/* Execute the fault part of 
the block / */ 

• BLOCK(/+l) = BLOCK/F 

• If number of blocks influenced 
by block i > threshold, then goto 
Simulation 

• Order the array Block, such 
that only the relevant blocks 
will be executed 

Simulation: 

• Restore the previous state of the 
simulator 

• Goto BLOCK(0 




/ype-fault-injection-procedure (INP, GOOD) returns: set-of-fault-values 

set-of-fault-values = 0 
for each ffv possible 
if ffv is of the form + 2 s ( - 2 s ) then do 
if SBD //V = vj(V]) then 

if bit 5 of GOOD = 0 (1) then x = GOOD with bit s inverted 
add x to set-of-fault-values 
else if INP e SBD //V then x = GOOD + ffv 

add x to set-of-fault-values, 
else if INP 6 MBD //V then x = GOOD + ffv 

add x to set-of-fault-values 
else if INP e MBD //v then x = GOOD + ffv 

add x to set-of-fault-values 


Figure 6. Template for a type-specific fault injection procedure. 
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• If there was detection, update 
relevant counters 

• I f there are more faulty machines 
to run, goto Simulation 

• Restore the array Block to its 
original state 

This structure is mostly self- 
explanatory, but there is one step that 
requires some elaboration. In general, it is 
possible to assign values to the label vari¬ 
ables Block(i) to bypass those blocks in the 
faulty design that are not affected by the 
fault (their outputs retain their fault-free 
values). 

Thus, we keep an influence graph from 
which this information can be extracted, 
so that only blocks possibly affected by the 
fault need to be resimulated. Sometimes, 
only a small percentage of the blocks 
would be skipped, and the reassignment of 
values to the labels is a time-consuming 
operation. Therefore, we empirically 
determined the trade-off between the time 
needed to reassign labels and the time sav¬ 
ings that result from the reassignment (in 
the form of blocks that are not resimu¬ 
lated). This trade-off determines that, 
whenever the block containing the fault 
being simulated influences less than 20 
percent (the threshold) of the total num¬ 
ber of blocks that would be simulated (that 
is, appear between the faulty block and the 


end of the compiled'code), reassignment 
of the label variables is performed. Other¬ 
wise, reassignment is bypassed, and all 
blocks “downstream” from the faulty 
block are resimulated. 

If the design being fault simulated 
exhibits sequential behavior, additional 
bookkeeping is required to keep a consis¬ 
tent account of each F-fault between simu¬ 
lation cycles. This is needed since an 
F-fault injected in a certain cycle might not 
be detected in the same cycle, but rather 
remain “hidden” for some time. Also, 
additional injections of the same F-fault 
might or might not occur, depending on 
the inputs being applied at each cycle. 

The results from a fault simulation run 
consists of sets of counters. In the next sec¬ 
tion, we relate these counters to the infor¬ 
mation produced by Detent (as explained 
in the “Overview of Whistle” section) and 
show how they are used to estimate the 
fault coverage of a design. 

Results analysis 

Basically, any fault simulation process 
should yield at least the answer to one 
question: Which faults were detected by a 
given set of test patterns? For gate-level 
fault simulators, there is a one-to-one cor¬ 


respondence between the faults as seen by 
the simulator and those of interest to the 
designer/user. In our case, this correspon¬ 
dence is slightly more involved, as shown 
in Silberman and Spillinger 9 and summa¬ 
rized below. Within Whistle, the tool 
Cover (see Figure 1) handles all tasks 
related to fault coverage calculations. 

In addition to this basic mode of oper¬ 
ation, in which all F-faults in the design are 
candidates for detection by the set of test 
patterns, the fault simulator has two other 
modes of operation, zoom and profile, 
which provide support for the test pattern 
generation approach suggested in Silber¬ 
man and Spillinger. 8 Zoom mode is used 
to examine a particular F-fault in a given 
block, fault simulate this F-fault for a 
given set of test patterns, and select from 
this set those patterns that cause detection 
of the F-fault. The profile mode is similar 
to zoom mode, but it fault simulates all the 
F-faults in the chosen block. Usage of 
these two modes will become clear when 
we discuss the test generation support in 
Whistle. 

Estimation of the implementation fault 
coverage. Recall from the “Overview of 
Whistle” section that, for each vector 
appearing at the input to a block during 
fault simulation, we apply a characteriza¬ 
tion function to determine which F-faults 
must be injected (by adding ffv-s to the 
block’s output). In addition, in case there 
was a detection, we want to characterize 
those I-fault(s) that might be covered by 
such a detection. From Silberman and 
Spillinger 9 , the probability that a given I- 
fault (in a given block), say I-faultj, has 
been detected, is 

V/v . 

wj = l — 71 71 (i - P' yv/v 

V//vSFF , = 1 


where P' = |SF}/ ViJ | +1 A} /v | with 
SF//vj(A//„) being the subset of vectors 
from SF //VJ (SBD// y U MBD //v ) for which 
/, the characterization function chosen by 
Detent, yields a value of /, and Njf V counts 
the number of detections for F-fault ffv, 
when/equaled i for the input to the block 
containing I-fault y . Notice that each F- 
fault can have a different characterization 
function, thus their domains may vary in 
size, a fact reflected by subscripting the 
domain size k. 

From the above formula for w y , we can 
clearly see the impact on performance of 
the characterization functions chosen by 


FA2-fault-injection-procedure (INP, GOOD) returns: set-of-fault-values 
del S(2) bit, X(l) bit 
set-of-fault-values = <t> 


F = GOOD with bit 2 inverted 

/♦Take care of 

V 

add F to set-of-fault-values 

/*ffv = -4 and ffv =4 

V 

F = GOOD with bit 1 inverted 

/♦Take care of 

7 

add F to set-of-fault-values 

/*//v = -2 and ffv =2 

7 

F = GOOD with bit 0 inverted 

/.* Take care of 

7 

add F to set-of-fault-values 

/*ffv = - 1 and ffv = 1 

7 


S = INP(2) + INP(3) + INP(4) 

X = INP(O) xor INP(l) 

if S(0) 11 X = ‘11 ’B then F = GOOD - 2 /* if INP eMBD~ 2 V 

add F to set-of-fault-values 

if S(0) 11 X = ‘01’B then F = GOOD +2 /* if INP e MBD +1 7 

add F to set-of-fault-values 


Figure 7. Fault injection procedure for the FA2 block. 
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Detent for each ffv. Not only should their 
evaluation be as efficient as possible, but 
they should also have the smallest possible 
domain k ffv , since this is the number of 
counters that must be kept during fault 
simulation, and thus impacts its memory 
requirements. 

Since the detection probability of each 
I-fault in a block, as shown above, is 
independent of other I-faults, the fault 
coverage of a block is simply given by 
W = Iwj. After calculating the fault 
coverage W for each block in the design, 
Cover estimates the total fault coverage by 
dividing their sum by the total number of 
I-faults in the design. 

Support for test pattern generation. The 

approach suggested in Silberman and 
Spillinger 9 for test pattern generation 
consists of three phases. Initially, the 
design is fault-simulated with a set of ran¬ 
dom patterns until the fault coverage curve 
flattens out. From the fault coverage at 
this point, obtained using the above for¬ 
mula for the detection probability of each 
I-fault, those blocks with low fault cover¬ 
age estimates are selected for processing in 
the second phase. This phase consists of 
generating biased-random test patterns, 
each guaranteed to excite a given F-fault 
of the block in question, and checking for 
detection by fault simulation. Also during 
this phase, for F-faults particularly diffi¬ 
cult to detect because of observability 
problems, an attempt is made to obtain a 
profile for patterns that would “open” 
paths for observability. The third phase 
corresponds to deterministic test pattern 
generation. 

By supplying the three modes of opera¬ 
tion during fault simulation, Whistle sup¬ 
ports the above approach. Basic mode is 
used for the first phase (random test pat¬ 
terns) or for any application that requires 
evaluating the fault coverage of a set of test 
patterns. The second phase uses both 
zoom and profile modes. While the use of 
zoom is quite straightforward, the profile 
mode merits some attention. As explained 
above, this mode picks from a set of vec¬ 
tors all those that cause detection of F- 
faults in a given block. From this set we 
must derive some characterization of the 
patterns that open a path for observabil¬ 
ity through this block. As suggested in Sil¬ 
berman and Spillinger, 9 we produce a set 
of weights by counting the relative num¬ 
ber of 1 ’s in each bit position of the set of 
patterns and merge this information with 
the biasing required for the excitation of 
an F-fault. 


In addition to detection probabilities 
from the fault simulation results, Cover 
calculates other quantities needed by the 
test generation process BRTPG. 8 These 
are 

• the block number in the design and an 
F-fault therein, which is the best can¬ 
didate (in the sense that its detection 
will yield the largest increase in fault 
coverage) for biased-random test 
generation; 

• the number of detections N for the 
chosen F-fault that will exploit the 
contribution of this F-fault to the 
overall fault coverage to the maxi¬ 
mum; and 

• the number of test patterns Mwe have 
to generate so that, according to our 
estimates, N of them will cause detec¬ 
tion of the chosen F-fault. 

BRTPG consists of two programs, 
Gentest for generating a set of biased- 
random test patterns guaranteed to excite 
(but not guaranteed to detect) a given F- 
fault in the design and Hardtest, which 
also incorporates observability weights 
into the biasing for the test patterns. Gen¬ 
test receives the selected block number and 
F-fault from Cover and the quantities N 
and Mas defined above. Using a backtrac- 
ing process similar to the one found in 
some gate-level test generation algorithms 
(for example, D-algorithm, PODEM, and 
FAN 11 ), Gentest creates a number of tem¬ 
plates of 0, 1, or X (“don’t care”) values 
for the inputs to the design, which will 
cause excitation of the chosen F-fault. 
From these templates, a set of test patterns 
is produced and evaluated by fault simu¬ 
lation (using the zoom mode), according 
to the process outlined below. 

Call Gentest 

Repeat 

Take a template 
Create a set of M vectors by 
randomly replacing every X bit by 
Oor 1 

Run the simulator to see if there is 
detection 

Save the vectors for which there 
was detection 

until N detections or no more 
templates 

If no detections are observed, the prob¬ 
lem must be with the lack of a path for 
observability. In this case, we invoke the 
program Hardtest to attempt a solution. 
Hardtest uses the profile mode to obtain 
information about blocks along possible 


observability paths, then uses this infor¬ 
mation to modify the templates produced 
by Gentest. 

The vectors obtained by applying 
BRTPG to a given F-fault are run again 
through the fault simulator, this time in 
basic mode, to evaluate their true contri¬ 
bution to the overall fault coverage of the 
design. This is done in an incremental fash¬ 
ion, that is, only F-faults that have not 
been detected a sufficient number of times 
are considered. The whole process is 
repeated until it is estimated that the effort 
to be invested (as reflected by the values of 
/Vand M) is comparable to that of deter¬ 
ministic test pattern generation. At this 
point, a list of I-faults with low detection 
probabilities is produced, to be used as 
input to the third phase in the test genera¬ 
tion process, where more traditional (gate- 
level) algorithms (such as D-algorithm, 
PODEM, or FAN) can be used to increase 
the fault coverage. 


Results and 
performance 

In this section, we evaluate Whistle 
from several points of view. First, we illus¬ 
trate the accuracy of the fault coverage 
estimates obtained by Cover by compar¬ 
ing it with the actual fault coverage 
obtained by gate-level fault simulation. 
Second, we examine the correlation 
between the accuracy measurements as 
given by our evaluation functions and the 
behavior of various characterization func¬ 
tions for a given block. This will illustrate 
how critical it is to choose a good charac¬ 
terization function and how it affects the 
accuracy of the results. A third aspect of 
Whistle that we look at is its test genera¬ 
tion capability, as implemented by 
BRTPG. 

Accuracy of Cover. For this task, we 
created several combinatorial designs, 
using a library of six different functional 
blocks. These blocks are similar to those 
used by LSI Logic Corp. in its macrocell 
designs and include a 2-to-4 decoder, an 
8-to-l multiplexer, an 8-to-3 encoder, a 
4-bit carry lookahead adder, a 2-bit binary 
full adder, and a 4-bit comparator. The 
designs were randomly generated, that is, 
the types of blocks and their interconnec¬ 
tion were chosen using a random function. 
Next, the designs were expanded into their 
gate-level equivalents by substituting each 
functional block with its description at the 
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Table 3. Characteristics for the sample designs. 




Number of 

Number 

Number 


Number 

Design Name 

Functional Blocks 

of Gates 

of F-faults 

of I-faults 

C899 


100 


2,138 

668 


8,110 

0185 


150 


3,039 

958 


11,640 

0690 


200 

4,117 

1,388 


15,681 

C2000 


250 

4,940 

1,702 


18,672 

Table 4. Estimated implementation fault coverage (in percentages). 


C899 0185 

Cl 690 

C2000 

Tests 

Est 

Diff Est 

Diff 

Est 

Diff 

Est 

Diff 

64 

83.0 

-1.3 83.6 

+ 0.8 

78.6 

+ 0.4 

78.9 

-0.1 

128 

89.3 

-1.4 89.9 

+ 0.5 

84.1 

+ 0.7 

84.8 

-0.0 

192 

90.9 

-1.5 92.0 

+ 0.7 

86.4 

+ 0.8 

87.5 

-0.0 

256 

92.0 

-1.5 93.5 

+ 0.4 

88.5 

+ 0.6 

89.1 

-0.1 

320 

92.9 

-1.7 94.4 

+ 0.3 

89.9 

+ 0.5 

89.9 

-0.3 

384 

94.2 

-1.9 95.1 

+ 0.3 

90.7 

+ 0.5 

90.8 

-0.4 

448 

95.1 

-1.9 95.5 

+ 0.2 

91.1 

+ 0.5 

91.4 

-0.5 

512 

95.5 

-1.8 96.3 

+ 0.2 

92.6 

+ 0.3 

92.0 

-0.4 

576 


96.6 

+ 0.1 

93.6 

+ 0.2 

92.3 

-0.6 

640 


96.8 

+ 0.1 

94.1 

+ 0.2 

92.6 

-0.7 

704 


97.2 

+ 0.1 

94.7 

+ 0.3 

92.8 

-0.7 

768 




94.8 

+ 0.3 

93.0 

-0.7 

832 




95.4 

+ 0.3 

93.2 

-0.8 

896 




95.5 

+ 0.3 

93.3 

-0.9 

960 






93.6 

-1.0 


Table 5. Detent characterization functions for 8-to-l multiplexer. 



Characterization Function 

Number of Counters 

//v=- 

E Detent 

1 //v=+1 

1 

khho 

8 

0.037 

0.063 

2 

/Vio 

4 

0.152 

0.122 

3 

ho 

2 

0.324 

0.382 

4 

Uniform Distribution 

1 

0.701 

0.643 

5 

khhh ® Uhkh 

16 

0.702 

0.639 


gate level. By assuming a single-stuck-at 
fault model, Dmat used these descriptions 
to obtain the necessary information for 
each block in the design library. Table 3 
summarizes the characteristics of four 
sample designs from among those we 
examined. Notice the l-to-10 ratio of F- 
faults to I-faults in each case and the 
difference (approximately 1 to 20) in the 
number of components (blocks or gates) 
for each design. 

For each design, we performed func¬ 
tional fault simulation using a set of test 


patterns and let Cover estimate the imple¬ 
mentation fault coverage. We then com¬ 
pared these results with those obtained by 
running the gate-level fault simulator 
HSS 12 on the equivalent gate-level 
designs, using the same stimuli. Table 4 
summarizes the results obtained, where the 
Diff column shows the difference between 
our estimates and the actual (from the 
gate-level fault simulation) fault 
coverages. 

From the results in Table 4, we see that 
the estimate follows very closely the actual 


implementation fault coverage (less than 
2 percent difference in either direction). 
We also applied the same procedure to 
other small examples of hand-coded 
designs with similar results, that is, the esti¬ 
mate differed from the actual fault cover¬ 
age by at most 2 percent in either direction. 


Evaluating a characterization function. 

To illustrate the importance of choosing a 
good characterization function and how 
this “goodness” is shown by our evalua¬ 
tion functions, we (randomly) generated a 
design with 50 blocks of the same type, an 
8-to-l multiplexer. Each such multiplexer 
has 11 input bits (eight data and three con¬ 
trol), labeled i 0 <j .. .; 10 , and one output bit 
(that is, FF = { + 1, -1}). 

First, using an optimal characterization 
function for Injent (that is, complete 
accuracy is maintained during the fault- 
injection process), we study the behavior 
of Cover for several characterization func¬ 
tions for Detent. Table 5 shows these func¬ 
tions and how accurate they are judged to 
be by the evaluating function E Detent for 
each F-fault. Figure 8 shows the fault 
coverage, as calculated by Cover, using 
each one of the characterization functions. 
Also shown is the actual fault coverage 
obtained using HSS on the gate-level 
description of the design. We can see that 
the closer the value of E Detent is to zero 
(for each F-fault), the smaller the gap 
between the fault coverage calculated by 
Cover and that obtained by HSS. 

Notice that the fifth function in Table 
5 has a domain of 16 values and thus 
requires 16 detection counters during 
simulation. This would seem to promise 
more accuracy in the results, but, as cor¬ 
rectly indicated by our evaluation func¬ 
tion, this is not the case (half the number 
of counters—eight—yields a much better 
result). 

Now, let us examine how important an 
accurate characterization function is for 
the case of Injent. To do so, we take the 
design described above and use the func¬ 
tions shown in Table 6 to decide when to 
perform fault injection. The fault cover¬ 
age results, as calculated by Cover, are 
shown in Figure 9. We can clearly see the 
correlation between the value of E| njen „ 
our evaluating function, and the accuracy 
of the results obtained by Cover. 

Test pattern generation by BRTPG. For 

this series of experiments, we took each of 
the designs described in Table 3 and used 
BRTPG to generate a set of test patterns. 
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Table 6. Injent characterization functions for 8-to-l multiplexer. 



Characterization Function 

for ffv = -1 (of not ffv = + 1) 

1 

o 0 and / 4 

0.887 

2 

o Q or /,o 

0.918 

3 

o 0 or i 4 or t’jo 

0.985 

4 

ho 

2.0 


Table 7. Fault coverage (in percentages). 


Tests 

C899 

C1185 

Cl 690 

C2000 

256 

93.5 

93.1 

87.9 

89.22 

320 

94.6 

94.1 

89.4 

90.19 

384 

96.1 

94.9 

90.2 

91.16 

448 

97.0 

95.3 

90.6 

91.90 

512 

97.6 

96.1 

92.3 

92.66 

576 


96.4 

93.4 

92.95 

640 


96.7 

93.9 

93.24 

704 


97.1 

94.4 

93.48 

768 



94.5 

93.75 

896 



95.2 

94.20 

960 




94.42 

Table 8. Code si; 

le (in bytes) for the sample designs. 




Gate-Level Code 

Functional-Level Code 

Design Name 

(using HSS) 


Assembly 

PL/1 

C899 

15,676 


10,164 

71,220 

C1185 

23,090 


14,350 

108,930 

Cl 690 

30,934 


19,852 

145,514 

C2000 

36,974 


24,160 

179,980 


Table 9. Time (in seconds) for block analysis. 


Functional Block 

CPU seconds (IBM 4381) 

2-to-4 decoder 

0.098 

8-to-l multiplexer 

0.516 

8-to-3 encoder 

0.235 

4-bit carry lookahead adder 

0.309 

2-bit binary full-adder 

0.147 

4-bit comparator 

0.170 


Table 10. Running times for 32 input patterns (in seconds). 


Design Name 

Gate-Level 

Fault Simulation 

Functional-Level 
Fault Simulation 

C899 

9.95 

5.40 

C1185 

19.75 

12.10 

Cl 690 

32.80 

20.39 

C2000 

45.00 

31.60 


As in the previous cases, the implementa¬ 
tion fault coverage was measured using 
HSS. The results obtained are summarized 
in Table 7 below (bold numbers mark the 
fault coverage achieved by flat, or uni¬ 
form, random patterns.) 

Simulator performance. To evaluate the 
performance of Hifast, we recoded most 
of its code in S/370 Assembly Language 
and then measured the amount of code 
produced for each sample circuit. We 
compared these to the original PL/1 code 
and to that required by HSS for the same 
circuits described at the gate-level. (The 
code measured is the “kernel” of the simu¬ 
lator in each case, that is, I/O and control 
portions are not included.) These measure¬ 
ments are summarized in Table 8. 

We can see that our Assembly code is 
about two-thirds the size of that generated 
by HSS. In addition, this code is about 
seven times smaller than the initial (PL/1) 
prototype code, a proportion that carries 
over almost unchanged to the execution 
phase because of the flatness of the code 
produced in both cases. Table 9 summa¬ 
rizes the CPU time (on an IBM 4381) spent 
in the analysis of each block in the library. 

Table 10 compares the running time for 
the functional fault simulator and HSS, 
both running on an IBM 4381. Since HSS 
processes 32 input patterns in parallel, we 
also run our simulator for 32 patterns, but 
in sequence. 

Considering that the initial version of 
Hifast produces straightforward sequen¬ 
tial code, without any parallelism or other 
optimizations, we view these first results 
as very encouraging. This, coupled with 
the other advantages offered by address¬ 
ing the tasks associated with testing at an 
early stage of the design cycle, make Whis¬ 
tle an interesting avenue for further 
developments. 

W histle, a workbench that sup¬ 
ports the development of test 
patterns for library-based 
designs, includes tools for the analysis of 
library blocks, a high-level fault simulator, 
and support for fault coverage estimation, 
as well as biased-random test pattern 
generation. 

The DFM approach to fault simulation, 
used as the basis for the tools in Whistle, 
has a “bottom-up” nature. As its basis, it 
requires a description of the library blocks 
used in the design of circuits. A very chal¬ 
lenging (and open) problem is to take the 
“top-down” view of the same process, 
where the implementation of a circuit is 
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not available (or known) when testing 
questions are considered, and still be able 
to provide meaningful results at the vari¬ 
ous stages of the design process. □ 
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Gentest 

An Automatic Test-Generation System 
for Sequential Circuits 


Wu-Tung Cheng and Tapan J. Chakraborty 
AT&T Bell Laboratories 


M odern VLSI devices push the 
limits of fabrication technol¬ 
ogy, so some devices will cer¬ 
tainly contain faults that will result in 
improper operation. It is vital that we de¬ 
tect faults as early as possible, but we can 
only do so if a high-quality test is available 
for the chip. We define high quality in 
testing as high fault coverage, that is, the 
test detects a high percentage of faults 
possible under a fault model. 

We can create tests in several ways. 
First, we can write them manually. For 
example, test vectors, a sequence of values 
provided to the circuit input, exercise the 
circuit and detect faults not detected by 
previous vectors. But writing vectors is a 
tedious and time-consuming process, of¬ 
ten taking months for large VLSI devices. 
So product introductions are often delayed 
until vectors are available, or vectors with 
inadequate fault coverage are used and 
customers receive lower quality devices. 

Second, we can let the circuit itself cre¬ 
ate the test vectors. A long sequence of 
random or pseudorandom patterns can 
thoroughly test a combinational circuit 
(one containing no memory devices). 
Modifying a circuit to create these patterns 
is called built-in self test. BIST is gaining 
acceptance in the industry, but it still has 
several disadvantages. First, BIST re¬ 
quires additional circuitry, increasing the 
cost of the chip. Second, it can slow down 



Gentest overcomes 
the inefficiency of 
previous automatic 
test generation 
methods for 
sequential circuits 
by combining a 
sequential test 
generator with a 
concurrent fault 
simulator. 


the chip, making it unacceptable for high- 
performance applications. Third, finding 
the exact fault coverage for a test vector set 
generated by BIST is difficult. Since the 
test sequence is long, fault simulation is 
expensive. Other techniques can provide a 
probabilistic estimate of the coverage, but 
not an exact one. 

Third, we can generate the test vectors 


automatically. Given a description of the 
circuit, automatic test-generation pro¬ 
grams deliver a set of vectors. ATG pro¬ 
vides clear, good fault coverage faster than 
manual techniques but with no overhead in 
the circuit itself. ATG’s major disadvan¬ 
tage is that it is not practical for every 
circuit; complete ATG algorithms guaran¬ 
tee finding a test for a fault if one exists, but 
finding the test can take excessive com¬ 
puter time. 

Overcoming this disadvantage for com¬ 
binational circuits is easier than doing so 
for sequential circuits (those with mem¬ 
ory). Since most practical circuits are 
sequential, scan design techniques convert 
sequential circuits into combinational 
ones. These techniques chain the flip-flops 
in the circuit into one or more shift regis¬ 
ters. Tests for the remaining combinational 
logic can then be scanned in, and the re¬ 
sults scanned out. Although scan design 
shares a drawback with BIST — circuit 
overhead — several companies have used 
it successfully. 

Still, many researchers have tried to 
develop a practical sequential ATG ap¬ 
proach. The difficulty of sequential test 
generation lies mostly in the large number 
of decision steps. In a combinational cir¬ 
cuit, a single vector propagates to the out¬ 
puts in one time step. If a test for a fault 
exists, the test will consist of exactly one 
vector. 
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Figure 1. Sequential circuit model. 


This is not the case for sequential cir¬ 
cuits. Consider a circuit containing a 16- 
bit counter, and consider a test — gener¬ 
ated for a stuck-at-0 fault at an AND gate’s 
output — that determines if the counter has 
reached the all-ones state. This test re¬ 
quires that all inputs to the AND gate be 1. 
The test generated for this fault would 
initialize the counter to all zeros and then 
clock it 2 16 -1 times. Since each clock re¬ 
quires two vectors, this test would require 
2*(2 ,6 -l) vectors. A person might write 
this test easily, or an ATG program that 
knows about counters might generate it 
easily, but it shows why circuits that are 
difficult to test cause problems for auto¬ 
matic techniques. Since ATG considers 
one flip-flop at a time, it does not know 
about the counter and would generate the 
test one vector at a time. (Incidentally, one 
solution to this problem breaks the counter 
into a group of smaller counters. If it were 
four sets of 4-bit counters, only 2 4 -l, or 15, 
clocks would be needed.) 

The first sequential test-generation al¬ 
gorithms were extensions of combina¬ 
tional test-generation algorithms, such as 
the D-algorithm 1 and the path-oriented, 
decision-making algorithm (Podem). 2 
Assuming that sequential circuits have 
clocked synchronous behavior, we can 
model them as being composed of two 
blocks: a combinational block C and a 
memory block //(see Figure 1). In block C, 
the vertical inputs are primary inputs to the 
circuit, the vertical outputs are primary 
outputs, and the horizontal inputs and out¬ 
puts are state inputs and outputs, respec¬ 
tively. 


Figure 2. Iterative logic array model. 


Figure 2 maps the time-domain behav¬ 
ior of a sequential circuit into the space 
domain. Here, each copy corresponds to 
circuit behavior at one time frame. Such an 
arrangement, composed of several copies 
of the combinational circuit, is also called 
the iterative logic array model. Using this 
model, sequential circuits are represented 
by equivalent combinational circuits. We 
can easily see how this model can extend 
combinational test-generation algorithms 
to sequential circuits; in fact, this has been 
done for the D-algorithm 3 6 and Podem. 7 
However, there are still difficulties. First, 
a single fault in the circuit has repeated 
fault sites at all frames in the iterative logic 
array model. Previous methods are incom¬ 
plete 35 ' 7 or inefficient in dealing with re¬ 
peated fault sites. 4 Second, some meth¬ 
ods 34 - 7 require saving the circuit status for 
each time frame in the test sequence, which 
can lead to excessive memory usage. Solv¬ 
ing these problems required a new ap¬ 
proach, which we have implemented in the 
STG2 sequential test generator using the 
Back test-generation algorithm 8 and the 
Split value model. 9 STG2 is an extension 
of STG1, described by Mallela and Wu. 6 

However, the test for one fault can de¬ 
tect many other faults. Running the test 
generator for all the faults would create a 
longer test sequence than necessary and 
would be very inefficient. For this reason, 
we have combined STG2 with the CSim 
concurrent fault simulator. 10 The com¬ 
bined system, called Gentest, submits the 
vectors created for fault detection to a fault 
simulator" ' 2 ; the detected faults are then 
removed from the list of faults to be con¬ 
sidered. 

In this article, we describe Gentest, with 
emphasis on STG2. We present Gentest’s 
architecture, describe the details of STG2, 
and present experimental results for STG2 
by itself and combined with Gentest on a 
set of benchmark circuits. 


Gentest architecture 

STG2’s basic function is to generate a 
test sequence for every target fault selected 
by Gentest. The next section offers more 
details on STG2. CSim’s basic function is 
to determine which faults are detected by 
the STG2-generated test sequences 
(Davidson and Lewandowski describe 
CSim in detail 10 ). The overall operation of 
Gentest is as follows. 

(1) The user can provide a fault list; 
otherwise, Gentest creates one after col¬ 
lapsing all equivalent faults. Equivalent 
faults are a group of faults that can be 
detected by the same test sequences. 

(2) Since test generation is time con¬ 
suming, the user can set a time limit or let 
it be generated by an experimental formula 
in STG2. 

(3) The user can provide some initializ¬ 
ing vectors or functional vectors that CSim 
will simulate to initialize the circuit. The 
fault list is updated if these vectors detect 
faults. 

(4) Gentest selects an untried and unde¬ 
tected fault as a target fault for STG2. If no 
such faults exist, the test-generation pro¬ 
cess is completed, and the generated test 
vectors, fault coverage information, and 
lists of detected, untestable, and unde¬ 
tected faults are reported. 

(5) STG2 tries to generate a test se¬ 
quence for the target fault. If there is no 
initial circuit state information (that is, if 
the values of all state elements are un¬ 
known), then the test sequence must in¬ 
clude vectors to set the state to a known 
value. For circuits with a long initializa¬ 
tion sequence, repeating the state initiali¬ 
zation for every target fault increases the 
test-generation time and the total test vec¬ 
tors generated. Since a new generated test 
sequence will be added to the end of the 
previous sequence, the final state informa¬ 
tion of the previous sequence is the initial 
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Table 1. Comparison of the five-valued 
model and the nine-valued model. 


1 2 3 4_5_6_Z_§- 



Figure 3. General model of a test sequence. 


state information of the new sequence. 
Therefore, after CSim’s fault simulation, 
STG2 treats the final state information as 
the initial state information for the next 
test-generation run. 

(6) Test generation can result in one of 
three cases. First, a test sequence can be 
generated to detect the target fault. CSim 
simulates this test sequence to update the 
fault list. The new sequence is added to the 
end of the previous sequence, and the final 
state information of the previous sequence 
becomes the initial state information in the 
fault simulation. Gentest then returns to 
step 4 and tries another target fault. Sec¬ 
ond, the target fault can prove untestable. 
Third, the time limit can be reached. In 
either of these cases, Gentest returns to 
step 4. 

The test generator 

Before describing STG2, we will review 
the problems of previous test-generation 
methods. 3 ' 7 

The previous problems. Figure 3 
shows a sequential circuit with a single 
stuck-at fault. Using the iterative logic 
array model, this fault has a repeated fault 
effect at every time frame. Each * is the 
fault site in each time frame. The values at 
the boundaries (the dotted lines) are state 
values. The primary inputs are at the top 
and the primary outputs are at the bottom. 
Assume that this fault can only be tested by 
a test sequence with eight test vectors. The 
curved lines are the paths sensitized by this 
sequence, which includes state initializa¬ 
tion to activate the fault effects and fault 
propagation to make the fault effects ob¬ 
servable at the primary outputs. 

The Podem algorithm needs to know 
that the propagation of fault effects should 
start after time frame 5. Otherwise, Podem 
will stop at time frame 4, since all the 


sensitized paths are blocked. However, 
having this information is almost impos¬ 
sible without knowing the test sequence. 
Therefore, Podem can be very inefficient 
in generating test sequences for sequential 
circuits. 

The test method described by Putzolu 
and Roth 3 uses the two-step approach of 
the D-algorithm to generate the test se¬ 
quence. First, sensitized paths carrying the 
fault effects are searched; this is called 
multiple-path sensitization. The paths are 
then established by justifying all the values 
required. However, this approach has the 
same problem as Podem at time frames 
1-4. 

To solve this problem, the five-valued 
model of the D-algorithm was extended to 
be the nine-valued model. 4 Table 1 com¬ 
pares the two models. Value i/j means 
“good machine has value i and bad ma¬ 
chine has value The nine-valued model 
lets us use single-path sensitization in the 
£>-algorithm. Instead of searching all sen¬ 
sitized paths in the first step, single-path 
sensitization searches only one sensitized 
path that reaches the primary output. With 
the nine-valued model, sensitized paths 
not found in the first step can be generated 
during justification. The nine-valued D- 
algorithm used by Muth 4 is a complete 
algorithm for sequential circuits if the good 
machine and the bad machine are initial- 
izable. 

However, compared to the five-valued 
model, the nine-valued model is very inef¬ 
ficient during justification. In the five¬ 
valued model, only nonsensitized values 
are processed for justification. In the nine¬ 
valued model, the sensitized values are 
also processed to allow implicit derivation 
of the sensitized paths. Therefore, all nine 
values must be used during justification, 
while only three values are used in the five¬ 
valued model. Thus, the .nine-valued 
model has the following efficiency prob¬ 
lems: 


Valued 

Valued 

0 

0/0 

1 

1/1 

D 

1/0 

D 

0/1 

X 

X/X 


0/X 


X/0 


1/X 


X/l 


(1) To justify an W-input gate’s output 
value, there are N 2 choices in the nine¬ 
valued model but only N choices in the 
five-valued model. For example, to justify 
an output value of 0/0 for a two-input AND 
gate, four input choices are available: 
(0/0,X/X), (X/X.0/0), (0/X.X/0), and 
(X/0,0/X). However, there are only two 
choices in the five-valued model: (0,X) 
and (X,0). Therefore, the search space in 
the nine-valued model is bigger. 

(2) No simple testability guidance can 
rank these N 2 choices. Thus, choosing 
correctly during justification is difficult. 

Because of the efficiency problems, 
previous test generators 3,5 ' 7 assume that 
the test sequence in Figure 3 does not have 
sensitized paths at time frames 1-4. There¬ 
fore, they are not complete, since they find 
no test for some testable faults. To be a 
complete test generator without excessive 
memory requirements, STG2 uses the 
Back 8 algorithm and the Split 9 value 
model. 

The Back algorithm. When a test se¬ 
quence for a target fault is applied to the 
circuit, a sensitized value should appear on 
at least one of the primary outputs. With 
this basic requirement, the Back algorithm 
predicts that one primary output will have 
the needed value and justifies this value 
backward through the circuit and through 
time to generate the test sequence. It is 
worth noting that the Split value model 
will create all the needed sensitized paths 
automatically when the sensitized primary 
output is justified. The Back algorithm 
proceeds as follows. 

(1) The algorithm selects the primary 
output most likely to have a sensitized 
value. This is the first and the most critical 
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Figure 5. The Split value model. 


decision. To guide this decision, we have 
developed a new testability measurement 
called drivability (see the subsection en¬ 
titled “Testability guidance”). If no pri¬ 
mary output can have a sensitized value, 
this fault is not testable. 

(2) The algorithm justifies the values 
required at the current time frame. If no 
conflict occurs, it proceeds to step 3. Oth¬ 
erwise, it backtracks to the previous deci¬ 
sion point. If no decision points remain, it 
returns to step 1. 

(3) The test sequence has been found if 

the state input requirements of the current 
time frame match the initial state values. 
Otherwise, the algorithm moves the cur¬ 
rent time frame to the previous time frame 
such that the state input requirements be¬ 
come the state output value requirements. 
The algorithm then returns to step 2. 

By trying all the primary outputs, the Back 
algorithm is as complete as the nine-valued 
D-algorithm for sequential circuits. 


Similar to Marlett’s extended backtrace 
method, * 2 3 * 5 the Back algorithm justifies time 
frame by time frame. In this manner, all the 
requirements of one time frame can be 
handled simultaneously. Thus, the circuit 
status need not include any time frame 
after the requirements of that time frame 
are satisfied. Furthermore, the output value 
requirement for every functional element 
can be justified by its input value (current 
time frame) and its state value (previous 
time frame). Therefore, the circuit status 
has to contain at most two time frames — 
the current and previous time frames — 
during test generation, independent of the 
number of sequential elements in the cir¬ 
cuit. Thus, the Back algorithm’s memory 
requirement is minimal. 

The Split value model. Similar to the 
nine-valued £>-algorithm, the Back algo¬ 
rithm has to process sensitized values 
during justification. To improve its per¬ 
formance, the nine-valued model was fur¬ 
ther extended to be the Split value model. 

We can use the circuit structure in Fig¬ 
ure 4 to explain the inefficiency of the 
nine-valued model. Basically, the nine¬ 
valued model views the good machine and 
the bad machine as two independent 
subcircuits with the same primary inputs. 
Each subcircuit has its own circuit status. 
However, the nine-valued model combines 
the values in these two subcircuits to re¬ 
duce the memory needed to store the cir¬ 
cuit status. In this arrangement, both 
subcircuits must be justified simultane¬ 
ously. Assume that a conflict occurs in the 
good machine and that the whole process 
backtracks to the previous justification 
decision to try another input choice for an 
element with an output value requirement. 
The new choice and the old choice can 
change only the bad machine input values 
to this element. If both machines are really 
independent, the new choice will not re¬ 
solve the conflict. Therefore, justifying 
two independent subcircuits simultane¬ 
ously increases the number of backtracks 
and the time wasted. 

To overcome this problem, we first split 
the nine values into two sets of three values 
for the good machine and the bad machine, 
respectively. With separate storage for 
their circuit statuses, the good machine and 
the bad machine can be justified sepa¬ 
rately. The efficiency problems of the nine¬ 
valued model can be solved as follows. 

(1) To justify an A-input gate’s output 
value in one machine, there are at most A 
choices, as in the five-valued model. Since 


we justify each machine separately, we 
avoid remaking the decision of one ma¬ 
chine to resolve the conflict in the other. 

(2) Since we justify each machine sepa¬ 
rately, we can use the testability measure¬ 
ment of each machine to rank the available 
choices. 

Furthermore, the Split model uses de¬ 
fault value 13 to yield a better result. For 
example, assume there are two choices, 
(0,X) and (X,0), to justify a value 0 at the 
output of a two-input AND gate. If the first 
choice (0,X) fails, the second choice will 
be (X,0). Since (0,0> was already ruled out 
as part of the failure of (0,X), the second 
choice is (1,0) by default. Default values 
can reduce the number of backtracks sig¬ 
nificantly. 

Actually, the good and bad machines are 
not independent. They differ at the fault 
site only and have almost identical circuit 
statuses. We define the value at the good 
machine as the good value, the value at the 
bad machine as the bad value, and the 
relation between the good and bad ma¬ 
chines as the relation (see Figure 5). The 
good and bad values can be 0, 1, X (don’t 
care), and Z (high impedance). We also 
define lines with unequal good and bad 
values as sensitized lines, and lines with 
equal good and bad values as nonsensi- 
tized lines. Therefore, the relation can be 
nonsensitized, sensitized, or unknown. In 
the Split value model, the circuit status 
includes this relation information. 

At first, from the topological informa¬ 
tion, the lines that cannot be affected by the 
fault site are nonsensitized lines. During 
test generation, the number of nonsensi¬ 
tized lines increases dynamically. When a 
test sequence is generated, the whole cir¬ 
cuit (except the sensitized paths) should 
have nonsensitized lines only. The search 
space becomes more restricted as more 
nonsensitized lines are identified. Since 
the good and bad values are recorded sepa¬ 
rately, the machines are justified sepa¬ 
rately. With relation information, the 
search space will be further restricted. The 
dynamic identification of the relation in¬ 
formation in the Split model proceeds as 
follows. 

(1) If all the inputs of an element are 
nonsensitized lines, then all the outputs 
must be nonsensitized lines. 

(2) If any output of an element is a 
sensitized line, then at least one input must 
be a sensitized line. 

Besides improving the performance of 
test generation, the Split model is easy to 
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Table 2. Characteristics of circuits for experiment. 


Circuit 

Gates 

Pi 

Po 

I/O 

Bus 

FF 

Faults 

c432 

160 

36 

7 

0 

0 

0 

524 

c499 

202 

41 

32 

0 

0 

0 

758 

c880 

383 

60 

26 

0 

0 

0 

942 

cl355 

546 

41 

32 

0 

0 

0 

1,574 

cl 908 

880 

33 

25 

0 

0 

0 

1,879 

sl03 

69 

8 

4 

0 

0 

4 

127 

sl57 

105 

10 

4 

4 

0 

4 

181 

s 181 

133 

12 

4 

6 

0 

4 

193 

s455 

395 

21 

15 

0 

0 

33 

408 

si 197 

780 

13 

13 

0 

12 

39 

1,063 


Table 3. Results for STG2. 


Circuit 

Time 

Detected 

Untestable 

Dropped 

Efficiency 

c432 

41.76 

520 

1 

3 

99.43 

c499 

90.96 

750 

8 

0 

100.00 

c880 

56.52 

942 

0 

0 

100.00 

cl355 

377.76 

1,566 

8 

0 

100.00 

cl 908 

356.63 

1,870 

7 

2 

99.89 

sl03 

12.36 

127 

0 

0 

100.00 

sl57 

16.55 

169 

11 

1 

99.45 

s 181 

13.36 

155 

38 

0 

100.00 

s455 

138.04 

314 

68 

26 

93.63 

si 197 

570.84 

822 

129 

112 

89.46 


implement with new types of circuit ele¬ 
ments. For example, if a circuit contains 
bus elements, the high impedance value 
must be used to avoid generating test vec¬ 
tors that cause bus conflicts. To include the 
high impedance value, the nine-valued 
model increases to 16 values 5 and the five¬ 
valued model grows to 23 values. How¬ 
ever, dramatically increasing the number 
of values increases the search space and 
complicates test generation. Including the 
high impedance value in the Split model 
adds only one extra value to the circuit 
status for the good machine and the bad 
machine. In this arrangement, the over¬ 
head of adding extra values in the Split 
model is minimal. 

Testability guidance. Two testability 
measurements guide decision-making in 
conventional test generators. The control¬ 
lability of a line measures the difficulty of 
placing a specific logic value on that line. 
There are two controllability values of 
each line for logic 0 and logic 1. The 
observability of a line measures the diffi¬ 
culty of observing the fault effect at that 
line from the primary outputs. Each line 
has only one observability value. Both 
measurements are calculated based on the 
good machine. Observability guides the 
sensitized-path selection, while controlla¬ 
bility guides the line-value justification. 

The Back algorithm does not use ob¬ 
servability, since there is no sensitized- 
path selection. As mentioned previously, 
the Back algorithm uses drivability, which 
corresponds to observability and measures 
the difficulty of driving the fault effect 
from the fault site to a line. Observability is 
calculated from the primary outputs back 
to the primary inputs, while drivability is 
calculated from the fault site forward to the 
primary outputs. Since drivability depends 
on the fault site, it must be calculated for 
every target fault. Our experiments show 
that the overhead to calculate drivability is 
insignificant compared to test-generation 
time. Since the fault site can have a sensi¬ 
tized value of only 1/0 or 0/1, the drivabil¬ 
ity of 1/0 and 0/1 can differ greatly at some 
lines; thus, STG2 uses two drivability val¬ 
ues for each line. 

Other test generators use only controlla¬ 
bility during justification. However, the 
Back algorithm also justifies sensitized 
values. Using controllability to guide the 
justification of sensitized values leads the 
process toward the primary inputs instead 
of the fault site. Using drivability solves 
this problem. Therefore, if the relation is 
sensitized, the Back algorithm uses the 


drivability measurement; otherwise, it 
uses the controllability measurement. 

Experimental results 

As mentioned earlier, STG2 was modi¬ 
fied from STG1. 6 STG1 uses the extended 
backtrace method 5 and the nine-valued 
model, 4 and STG2 uses the Back algorithm 
and the Split value model. We have also 
implemented the STG 1.5 experimental test 
generator using the D-algorithm and the 
Split value model. Cheng’s results 9 show 
that STG 1.5 performs better for combina¬ 
tional circuits than a test generator using 
the Podem algorithm and the five-valued 
model. However, STG2 has shown the best 
fault coverage and total test-generation 
time among all three test generators; hence, 
we chose to incorporate it in Gentest. 

STG2. All three test generators use the 
same kind of testability measurements. We 
compared their performance on a Convex 
C-l computer using the circuits whose 
characteristics appear in Table 2. The first 


five circuits are Brglez-Fujiwara combina¬ 
tional benchmark circuits 14 ; the others are 
AT&T sequential circuits. Here, I/O pins 
can be either input pins or output pins but 
not both; p, and p 0 are the primary inputs 
and outputs, respectively. We used a high 
impedance value in STG2 to avoid con¬ 
flicts at I/O pins and bus elements. “FF” is 
the number of flip-flops. The fault list was 
generated after collapsing all the equiva¬ 
lent faults. Since we did not use a fault 
simulator, each test generator tried every 
fault in the fault list, and no initial state 
information was available for any target 
fault. We set the CPU time limit to two 
seconds per fault. 

Table 3 shows the detailed results for 
STG2. Time is the sum of the test-genera¬ 
tion time in seconds for all the target faults. 
Efficiency is the sum of detected and un- 
testable faults divided by the total faults. 
Since we did not use a fault simulator, we 
do not know the real fault coverage. Table 
4 compares efficiency and time for all 
three test generators. STG2 spent more 
time than STG 1.5 for circuits c499 and 
c880, showing that the overhead to calcu- 
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late drivability for every target fault could 
be high for easily testable circuits. How¬ 
ever, the overall effect of this overhead for 
other circuits is improved efficiency and 
reduced test-generation time. 

Gentest. We carried out another set of 
experiments for Gentest on a Sun 3/60 
workstation. Table 5 shows the character¬ 
istics of the experimental sequential cir¬ 
cuits used, including the number of total 
faults after collapsing all the equivalent 
faults and the time limit for each target 
fault. 


Table 6 shows our. results. Time is the 
total CPU time spent in each circuit, in¬ 
cluding test-generation time, fault-simula¬ 
tion time, and communication time be¬ 
tween them. For each circuit, the table lists 
the number of target faults tried, the num¬ 
ber of untestable faults identified, and the 
number of test sequences generated by 
STG2. These test sequences were concate¬ 
nated one by one to get the final test se¬ 
quence. The number of vectors is the size 
of the final test sequence. Table 6 also lists 
the number of faults detected by CSim. 
Fault coverage is the sum of untestable 


faults identified by STG2 and detected 
faults identified by CSim, divided by the 
total number of faults. 

It is worth noting that the number of 
STG2-generated test sequences for test¬ 
able faults is much smaller than the num¬ 
ber of detected faults identified by CSim. 
This discrepancy indicates that a fault 
simulator can dramatically reduce the 
number of time-consuming test-genera¬ 
tion runs. However, we cannot reduce the 
number of STG2 runs to identify the untes¬ 
table faults. As a result, the identification 
of untestable faults can be critical to the 
total test-generation time. STG2 reached 
the two-second time limit for more than 
200 target faults in each circuit of logic6 
and mickey; thus, low fault coverage was 
achieved. Increasing the time limit would 
probably improve fault coverage. 


G entest has been used successfully 
in the field for sequential circuits. 
However, the communication 
overhead between STG2 and CSim is sig¬ 
nificant. Our future research will focus on 
developing a built-in, efficient fault simu¬ 
lator inside STG2 or a built-in, efficient 
test generator inside CSim. 

Future work on test-generation algo¬ 
rithms should concentrate on functional 
faults and bigger, more complex circuits. 
Therefore, speeding up the automatic test- 
generation process is desirable. Using 
high-level models or primitives can speed 
up the overall test-generation process. For 
example, if high-level models like shift 
registers, counters, arithmetic logic units, 
etc., are functionally defined, then using 
them instead of their gate-level representa¬ 
tions in test generation or fault simulation 
could speed up the test-generation process. 
Though several researchers are working on 
this problem, an algorithm using high- 
level primitives is not well defined yet. CD 


Table 4. Comparison of results for STG1, STG2, and STG1.5. 


Circuit 

STG1 

Efficiency 

STG2 

STG1.5 

STG1 

Time 

STG2 

STG1.5 

c432 

82.25 

99.43 

98.66 

262.29 

41.76 

42.94 

c499 

86.81 

100.00 

100.00 

828.13 

90.96 

74.05 

c880 

100.00 

100.00 

100.00 

77.97 

56.52 

32.18 

cl355 

79.99 

100.00 

91.87 

1,314.65 

377.76 

634.28 

cl 908 

97.76 

99.89 

95.64 

705.21 

356.63 

383.32 

sl03 

94.49 

100.00 

NA 

35.46 

12.36 

NA 

sl57 

89.27 

99.45 

NA 

38.04 

16.55 

NA 

s 181 

81.77 

100.00 

NA 

43.82 

13.36 

NA 

S455 

NA 

93.63 

NA 

NA 

138.04 

NA 

si 197 

NA 

89.46 

NA 

NA 

570.84 

NA 


Table 5. Characteristics of circuits for Gentest experiment. 


Circuit 

Gates 

Pi 

Po 

I/O 

Bus 

FF 

Faults 

Limit 

Z99T 

99 

10 

4 

4 

8 

4 

281 

2 

20x8T 

95 

12 

8 

2 

10 

8 

231 

2 

22a31T 

100 

12 

4 

6 

10 

4 

220 

2 

video 

643 

49 

4 

0 

0 

110 

1,245 

10 

logic6 

262 

21 

15 

0 

0 

33 

723 

2 

dcounter 

37 

8 

4 

0 

0 

4 

95 

2 

arbT 

78 

10 

4 

4 

8 

4 

187 

2 

mickey 

644 

13 

13 

0 

25 

39 

1,270 

2 

ic73T 

337 

22 

16 

0 

0 

11 

1,230 

10 


Table 6. Gentest results. 


Circuit 

Time 

Trial 

Untestable 

Sequences 

Vectors 

Detected 

Coverage 

Z99T 

230 

86 

39 

26 

108 

230 

93.59% 

20x8T 

130 

47 

26 

8 

46 

203 

99.13% 

22a31T 

182 

66 

27 

32 

117 

186 

96.81% 

video 

14,400 

98 

0 

78 

4,038 

1,225 

98.39% 

logic6 

1,400 

358 

71 

61 

283 

534 

83.68% 

dcounter 

100 

17 

4 

13 

44 

91 

100.00% 

arbT 

475 

87 

22 

45 

108 

149 

91.44% 

mickey 

2,873 

454 

216 

36 

260 

947 

91.57% 

ic73T 

11,530 

558 

431 

55 

1,124 

731 

94.14% 
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FULL AT&T C++: ANNOUNCING VERSION 1.2 

Guidelines announces its port of version 1.2 of AT&T’s C++ translator. As an 
object-oriented language C++ includes: classes, inheritance, member functions, con¬ 
structors and destructors, data hiding, and data abstraction. “Object-oriented” means that 
C++ code is more readable, more reliable and more reusable. And that means faster 
development, easier maintenance, and the ability to handle more complex projects. C++ 
is Bell Labs’ answer to Ada and Modula 2. C++ will more than pay for itself in saved 
development time on your next project. 


C++ 

from GUIDELINES for the IBM PC: $295 


Requires IBM PC/XT/AT or compatible with 640K and a hard disk. 
Note: C++ is a translator, and requires the use of Microsoft C 3.0 or later. 


Here is what you get for $295: 

• The full AT&T vl.2 C++ translator. 

• Libraries for stream I/O and complex math. 

• The C++ Programming Language, the 
definitive 327-page tutorial and description 
by Bjame Stroustrup, designer of C++. 

• Sample programs written in C++. 

• Improved installation guide and 
documentation. 

• 30-day money-back guarantee. 


NOW AVAILABLE FOR 
UNIX V/386 - $495 

To Order: 

send check or money order to: 

GUIDELINES SOFTWARE, INC. 
P. O. Box 749, Dept. CT 
Orinda, CA 94563 
To order with VISA or MC, 


phone (415) 254-9183. 

(CA residents add 6% tax.) 


C++ is ported to the PC by Guidelines under license from AT&T. 
Call or write for a free C++ information package. 
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Software through Pictures" 

“Delivering 


the Promise 


HIGH QUALITY SOFTWARE is 
the promise of CASE. 

IDE’s Software through Pictures 
increases productivity, 
establishes control, and 
improves communications. 

Everyone benefits when 
software is delivered on- 
time and within budget 
and when it matches the 
customer’s needs. In 
addition, projects 
designed right the first 
time have significantly 
lower maintenance costs. 

User-Extensible Applications 
Software through Pictures significantly 
increases productivity and improves design 
quality with applications such as: 

• Automatic Documentation, 

• Requirements Traceability, and 

• DOD-STD-2167 Support. 

Open Architecture 

The Software through Pictures 
integrated, multi-user CASE 
environment includes graphical 
editors supporting several 
popular analysis and design 
methods. Its open architecture 


allows users to incorporate other 
tools in their own integrated 
CASE environment. 

IDE’s Experience 

Since 1983, IDE has been helping 
customers succeed at each stage of 
their software development 
lifecycle by incorporating Software 
through Pictures into their 
development environments. 

Software through Pictures is 
available for the Apollo, DEC 
VAXstation (VMS and Ultrix), HP 
9000, and Sun Workstations. 
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Generating Single-Stuck-Fault 
Coverage from a 
Collapsed-Fault Set 

Mark A. Heap and William A. Rogers 


I ntegrated-circuit functionality and 
size have increased to the point that 
by 1994 we will have to support sys¬ 
tems of 10 8 logic elements and 10 u mem¬ 
ory bits. 1 Defective chips of this 
complexity are more likely to cause a sys¬ 
tem failure and are more expensive to 
replace. Thus, chip buyers and manufac¬ 
turers are demanding the lowest possible 
defect level, that is, a very low probability 
that a defective chip is shipped. 

The defect level is a function of yield ( Y) 
and testing (T), where yield is the proba¬ 
bility of manufacturing a good chip and 
testing is the verification of the chip before 
it is shipped. Without testing, the defect 
level will be one minus the yield; if the chip 
is completely tested, the defect level will be 
zero. 

Chips are tested by applying a set of sig¬ 
nals, the test set, to their inputs and verify¬ 
ing that the outputs match the known 
good-circuit outputs. If the output differs 
from the good-circuit output, an input pat¬ 
tern tests for the presence of a fault. The 
effectiveness of the test set is measured by 
its fault coverage—the fraction of faults 
that the test set tests. Fault coverage is 
generally determined by simulating the 
good and faulty circuits. Alternatives to 
fault simulation, such as critical-path trac¬ 
ing, 2 statistical fault analysis (Stafan), 3 
and fault-sampling techniques, 4-6 are far 
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Most fault simulators 
produce a test-coverage 
figure that does not 
accurately reflect true 
single-stuck-fault 
coverage. However, a 
better technique is 
available. 


less widely used. Statistical analysis is 
quicker than fault simulation because it 
actually simulates only a small, randomly 
selected sample of the faults. On the basis 
of this partial simulation, fault coverage 
is determined to be within a certain uncer¬ 
tainty range. We will show later that the 
limits of this range can give very different 
defect levels, especially as fault coverage 
approaches 100 percent. 

Fault simulation requires a fault model 
to predict the effect of a physical defect on 
a circuit. Although we know that not all 
physical faults map to a gate-level model, 


the most widely used fault model today is 
still the stuck-fmodel, which was essen¬ 
tially proposed by Eldred 7 in 1959. In the 
single stuck-at model, physical defects are 
modeled by assuming that one line in a 
gate-level circuit model will be stuck at 
logic 0 or i. Williams and Brown 8 have 
derived a defect-level model for single 
stuck faults (SSFs) that presents the defect 
level (DL) as a function of the manufactur¬ 
ing yield (y) and the SSF coverage (T)\ 

DL=\-Y l ~ T 

Note that for a low defect level, fault 
coverage must be very high, almost 
independent of the yield. The defect-level 
model depends on two assumptions that 
reduce its accuracy: Each fault is assumed 
to be independent of the others, and each 
fault is assumed to have an equal proba¬ 
bility of occurring. However, empirical 
results generally support the defect-level 
model, and high fault coverage is consid¬ 
ered a good figure of merit for a circuit. 

Fault simulators do not simulate all the 
SSFs, because as the simulated fault set 
grows, the increase in their runtime and 
memory requirements is greater than lin¬ 
ear. 9 Fault-set size is reduced, or col¬ 
lapsed, during circuit preprocessing by 
using the concepts of equivalence and 
dominance. Fault A is equivalent to fault 
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Figure 1. A four-input AND gate. 


B if their test sets are equivalent, and fault 
A is dominated by fault B if the test set for 
A is a subset of the test set for B. That is, 
if every possible test for A is also a test for 
B, then fault A is dominated by fault B; 
but if every possible test for B is also a test 
for A, then fault A and fault B are equiva¬ 
lent. The collapsed-fault (CF) set includes 
one representative from each of the 
equivalence classes and the dominated 
fault from each dominance class. For com¬ 
binational circuits the checkpoint faults— 
meaning the SSFs on primary inputs, fan¬ 
out branches, and XOR elements—are 
used as the CF set, and this set is then 
reduced even further by applying 
equivalence. 10 

This simulation of collapsed faults 
means that the fault coverages reported are 
CF coverages rather than SSF coverages. 
This article will show that CF coverage is 
not the same as SSF coverage and that this 
difference has a large effect on the defect 
level as the coverage approaches 100 per¬ 
cent. We present a very low overhead tech¬ 
nique that calculates true fault coverage 
while simulating with a collapsed-fault set, 
thereby retaining the runtime and memory 
savings of simulating with collapsed faults 
without sacrificing fault-coverage 
accuracy. This technique can be applied to 
any fault model exhibiting equivalence and 
dominance properties. 


SSF coverage vs. CF 
coverage 

Single-stuck-fault coverage and 
collapsed-fault coverage are not equiva¬ 
lent. Consider a four-input AND gate with 
10 SSFs and five collapsed faults (Figure 
1). A test pattern of 1111 will give 
50-percent SSF coverage and 20-percent 
CF coverage (Table 1). In a large circuit the 
difference in coverage is unlikely to be this 


Table 1. Fault sets and coverage for 
Figure 1. 


Fault Set Faults Total 

SSF A-E s-a-0/1 10 

CF A-D s-a-1, A s-a-0 5 


Pattern SSF Coverage CF Coverage 
1111 5 /o (50%) '/ s (20Vo) 


dramatic, but according to the defect-level 
model, even a small change in test cover¬ 
age T will significantly affect DL. 
Differentiating the model we get 

dDL = (In Y)Y' T dT 

This indicates that for a fixed Y, the higher 
the fault coverage the more a change in T 
will affect DL. Suppose F=0.5; then if 
T= 0.998, we project a DL of 
1.385 x 10“ 3 , but if T= 0.995, we project 
a DL of 3.460 x 10~ 3 . A 0.3-percent 
reduction in T produces a 150-percent 
increase in DL. If we keep Y= 0.5 but let 
T change from 0.9998 to 0.9995, then a 
0.03-percent reduction in T still produces 
a 150-percent increase in DL. This indi¬ 
cates that the choice of whether to use SSF 
coverage or CF coverage for T is impor¬ 
tant, because a small change in T produces 
a large change in DL, especially as T 
approaches 100 percent. 

Suppose we choose CF coverage as our 
figure of merit. The following derivation 
shows why the defect-level model is less 
accurate when using CFs than it would be 
using SSFs. With m the number of tested 
faults, n the total number of collapsed 
faults, A the event that none of the faults 
in the model occur, and B the event that 
none of the tested faults occur, Williams 
and Brown’s 8 derivation of the defect- 
level model proceeds as follows: 



y = 


(l -p) n 


P(A\B) 


P(AB) 
PiB) 


(1 ~P)" 
(i -pY 


DL = \-P(A\B) = 1 -Y' t 

Note that our fault model now consists 
of only the collapsed faults rather than all 


the SSFs. The defect-level model’s 
assumptions are still valid because the col¬ 
lapsed faults are just a subset of the SSFs, 
so if the SSFs are independent and have an 
equal probability of occurring, the CFs are 
also independent and have an equal prob¬ 
ability of occurring. 

However, the defect-level model is now 
less accurate because we are not taking into 
account the fact that the collapsed faults 
are merely weighted representatives of the 
SSFs. By using CF coverage as T, we are 
assuming that the coverage of one col¬ 
lapsed fault is just as valuable as the cover¬ 
age of any other. This assumption can only 
be made by ignoring the SSF model. Con¬ 
sider the circuit in Figure 2. According to 
the collapsed-fault model, each pattern is 
equally valuable despite the fact that one 
detects two SSFs and the other detects 
seven, as Table 2 shows. So traditional SSF 
coverage is generally a more accurate fig¬ 
ure of merit than CF coverage. 


The masking of 
detected faults by 
undetected collapsed 
faults 

The use of collapsed-fault coverage may 
introduce further inaccuracy if undetected 
collapsed faults mask detected single stuck 
faults. When we simulate with a CF set and 
certain CFs remain undetected, we assume 
that the SSFs dominating these undetected 
CFs are also undetected. But this is not 
necessarily true, because the test set for the 
dominating SSFs is larger than that of the 
dominated CFs. Masking occurs when the 
dominated CF is undetected but the 
dominating SSF is detected. 

Abramovici, Menon, and Miller 11 first 
pointed out that nondetectable checkpoint 
faults can mask other detectable faults. 
They explained this in terms of fault dom¬ 
inance by noting that although the detec¬ 
tion of a dominated fault implies the 
detection of all the faults dominating it, 
the fact that a dominated fault is 
undetected does not necessarily imply that 
all the faults dominating it are undetected. 
This is stated more formally in the follow¬ 
ing definition: 

Definition 1: Let A be a dominating 
fault that is not a member of the 
collapsed-fault set, let T A be the test 
set for fault A , and let DFbe the col¬ 
lapsed faults dominated by A. Then 
A is masked by an undetected col¬ 
lapsed fault if 
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t df =$ 


Note that since the input vectors are 
rarely exhaustive, by a null test set we do 
not mean that the fault is necessarily 
globally redundant, only that the fault is 
untested by these particular input vectors. 

As an example of undetected collapsed 
faults masking detected SSFs, consider J 
stuck-at-0 (J 0 ), K s-a-0 (K 0 ), and Ms-a-0 
(M 0 ) in the redundant implementation of 
(AB)' in Figure 3. Note that none of these 
faults is a member of the CF set (Table 3). 
Note also that / and K s-a-0 dominate the 
checkpoint faults C, D, and G s-a-1, and 
that M s-a-0 dominates the checkpoint 
faults C, D, F, and G s-a-1. This means 
that J, K, and M s-a-0 are dominating 
faults that are not members of the 
collapsed-fault set and therefore satisfy the 
requirements for A in Definition 1. Since 
we have only two inputs, we will use an 
exhaustive input set; so 

T Jo (A,B)=A’B 
T Ko (A,B)=A'B 
T Mo (A,B)=A' + B' 

We have now satisfied T A =£<)> in Defini¬ 
tion 1. Now note that C,D,F, and G s-a-1 
are redundant, so 


T C[ (A,B) = T Dl (A,B) 

= T Fi (A,B)=T Gi (A,B) = $ 

This satisfies T DF = <|> in Definition 1, and 
J, K, and M s-a-0 are detected faults 
masked by undetected collapsed faults. 

Let’s look at the effect this fault mask¬ 
ing has on the accuracy of the CF cover¬ 
age. Table 3 shows the results of 
simulating the circuit of Figure 3 with three 
different fault sets. SSF is the true single- 
stuck-fault set, EF is this set reduced by 
equivalence, and CF is the set reduced even 
more by dominance. The differences in 
coverage are due to the SSF weights in the 
EF case and to the SSF weights and the 
masking of the detected J, K, and M s-a-0 
in the CF case. Note that after the second 
test pattern only one CF has been detected. 
The CF coverage is lower than the true SSF 
coverage because the CF coverage does not 
take the detected J, K, and M s-a-0 into 
account. 

Of course, not all SSFs that dominate 
collapsed faults are masked by undetected 
dominated faults. In this circuit E s-a-1 
and H s-a-1 dominate the redundant col¬ 
lapsed faults C s-a-1 and D s-a-1. From 
Definition 1 we have T DF =\, but E s-a-1 



Figure 2. Example circuit for the single-stuck-fault weights of collapsed faults. 


Table 2. Fault sets and coverage for Figure 2. 



Fault Set Faults Total 

SSF A-/s-a-0/1 18 

CF A-D s-a-0/1 8 


Pattern 

CF Detected 

SSF Detected 

0000 

D s-a-1 (1) 

D s-a-1, 1 s-a-0 (2) 

0101 

A s-a-1 (1) 

D-H s-a-0; A, / s-a-1 (7) 







Figure 3. Example circuit for undetected collapsed-fault masking. 


Table 3. Fault sets and coverage for Figure 3. 


Fault Set Faults Total 

s-a-0 s-a-1 


SSF A-M A-M 26 

EF A-C, F, G, M A-G, J 14 

CF A-C, F, G _ A-D, F, G _11 


Pattern 

Additional Faults Detected 

Cumulative Fault Coverage 


s-a-0 

s-a-1 

SSF 

EF 

CF 

00 

M 


0.0385 (54.) 

0.0714(!/,) 

0.0000 (%) 

01 

J,K 

A 

0.15 3 8 ( 4 / 26 ) 

0.1429 0/,) 

0.0909 0/,) 

10 


B 

0.1923 (54.) 

0.2143 ( 3 /,) 

0.1818( 2 /,) 

11 

A-H 

I-M 

0.6923 (‘540 

0.6429 (’/,) 

0.6364( 7 /,) 
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Table 4. Fault graph (array form) for circuit in Figure 3. 



Fault 

Equiv. To 

Domin. By 

SSF Weight 

Detect 

L 

A 0 



1 


e 

B 0 



1 


V 

Co 

G 0 


9 


e 

Do 

C 0 


0 


i 

F 0 

Do 


2 



G 0 

Fo 


0 


i 

A, 



1 



B\ 



1 



C, 


Ey 

1 



A 


Ey 

1 



Fy. 


Mo 

3 



Gy 


Jo 

1 



Ey 


Jo 

2 


2 

M 0 



1 



Jo 


Mo 

2 



and //s-a-1 are themselves redundant, so 
we also have T A =\. This is contrary to 
the definition, so E and H s-a-1 are not 
masked by undetected collapsed faults. 


Generating single-stuck 
coverage while 
simulating with a 
reduced fault set 

As we have shown, to report SSF cover¬ 
age while simulating with a reduced fault 
set, we must take into account the SSF 
weight of each collapsed fault and the pos¬ 
sibility of undetected collapsed faults 
masking detected faults. The following is 
one way to do this: 


Table 5. Reduced fault graph (array form) for circuit in Figure 3. 



Fault 

Equiv. To 

Domin. By 

SSF Weight 

Detect 

L 

Ao 



1 

X 

e 

B 0 



1 

X 

V 

C 0 



11 

X 

e 

Ay 



1 

X 

1 

By 



1 

X 


Cy 


Ey 

1 


1 

Dy 


Ey 

1 



Fy 


Mo 

3 



Gy 


Jo 

1 



Ey 


Jo 

2 


2 

M 0 



1 



Jo 


M 0 

2 


Table 6. 

Final fault graph (array form) for circuit in Figure 3. 



Fault 

Equiv. To 

Domin. By 

SSF Weight 

Detect 

L 

Aq 



1 

X 

e 

Bo 



1 

X 

V 

C 0 



11 

X 

e 

Ay 



1 

X 

1 

By 



1 

X 


Cy 


Ey 

1 


1 

Dy 


Ey 

1 



Fy 


Mo 

3 



Gy 


Jo 

1 



Ey 


Jo 

2 


2 

Mo 



1 

X 


Jo 


Mo 

2 

X 


(1) Build a fault graph of the circuit, 
using the equivalence and dominance rela¬ 
tionships between faults. 

(2) Reduce the fault graph by combin¬ 
ing equivalent faults into equivalence 
classes. 

(3) Simulate with the collapsed-fault 
set; that is, simulate with one representa¬ 
tive from each equivalence class and the 
dominated fault from each dominance 
class. 

(4) Mark as detected all detected-fault 
classes and all faults that dominate 
detected faults. 

(5) Look at the undetected faults in the 
reduced set. Form a new collapsed-fault 
set from any undetected dominating 
faults. 

(6) If this new set is nonempty, go to 3; 
otherwise, calculate the true coverage 
using the weights from the detected faults 
in the reduced fault graph. 

This procedure can be used to calculate 
the true fault coverage for any circuit 
simulated with a fault set that has been col¬ 
lapsed with equivalence and dominance. 
The vertices in the fault graph are the 
SSFs, and the edges are equivalence and 
dominance relationships. A fault graph 
for a combinational gate-level circuit is 
built according to the following rules: 

• All pin faults, fan-out stem faults, and 
any other collapsed faults are considered 
root nodes. 

• All s-a-0 faults on inputs to 
AND/NAND gates are equivalent to each 
other and to s-a-O/s-a-1 on the output. 

• All s-a-1 faults on inputs to OR/NOR 
gates are equivalent to each other and to 
s-a-l/s-a-0 on the output. 
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• All faults on inputs to buffers are 
equivalent to the faults on the output. 

• All faults on inputs to inverters are 
equivalent to the inverse fault on the 
output. 

• All s-a-1 faults on inputs to 
AND/NAND gates are dominated by s- 
a-l/s-a-0 on the output. 

• All s-a-0 faults on inputs to OR/NOR 
gates are dominated by s-a-O/s-a-1 on the 
output. 

• Faults on a fan-out-free signal are 
equivalent. 

• All faults initially have an SSF weight 
of 1. 

These rules are just those of gate and sig¬ 
nal equivalence and dominance 10 and can 
be used to generate a collapsed set them¬ 
selves. 

As an example, let’s apply the procedure 
to the circuit in Figure 3. First we parse the 
circuit netlist and create the gate-level data 
structure just as we normally would before 
simulation. Then we begin building the 
fault graph by choosing an easily com¬ 
puted collapsed-fault set. As mentioned 
earlier, typically the checkpoint set— 
meaning the SSFs on primary inputs, fan¬ 
out branches, and XOR elements—is 
used. This gives us the 12 faults in the first 
level of the fault graph of Table 4. To build 
the fault graph, we process each of the 
faults in turn by starting at the fault loca¬ 
tion and traversing the circuit until we 
encounter another collapsed fault, a dom¬ 
inance condition, or a primary output. 
During this circuit traversal we sum up the 
SSF weight of each fault and record the 
dominating faults on the next level of the 
fault graph. When all faults on one level 
have been processed, we follow the same 
procedure with all faults on the next level. 

Suppose we are processing the fault Co- 
This fault is equivalent to Do, E 0 , H 0 , G 0 , 
, and My, so we give it a weight 
of 9. We then look at D 0 and note that C 0 
has already accounted for the equivalence 
at that gate, so we mark it equivalent to 
C 0 and give it a weight of 0. Next, F 0 is 
equivalent to Iy, which is equivalent to Ly, 
but again we note that the equivalence at 
this gate has already been accounted for by 
C 0 , so we give F 0 a weight of 2 and add it 
to the equivalence ring by marking it 
equivalent to D 0 . Similarly, G 0 is given a 
weight of 0 and marked equivalent to F 0 . 
Throughout these steps the fault that C 0 is 
marked equivalent to is constantly 
updated to the most recent equivalence 
relationship, so it ends up being marked 
equivalent to F 0 . 


To report SSF 
coverage while 
simulating with a 
reduced fault set, we 
must consider the SSF 
weight of each CF and 
the possibility of 
undetected CFs 
masking detected 
faults. 


For a dominance example, let’s look at 
the fault Gj. Gy is dominated by J 0 , so G\ 
is given a weight of 1 and marked domi¬ 
nated by J 0 , and J 0 is added as a fault on 
the next level. Similarly, Fy is equivalent 
to I 0 and L 0 , but L 0 is dominated by M 0 , 
so F\ is given a weight of 3 and marked 
dominated by M 0 , and M 0 is added as a 
fault on the next level. 

When all faults on the first level have 
been processed, we go to the next level. E, 
is equivalent to H u which is dominated 
by J 0 - We note that J 0 has already been 
recorded as a fault, so we do not need to 
add it on the next level. Ey is given a 
weight of 2 and marked dominated by J 0 . 
M 0 is a primary output and can be left 
alone, but J 0 is equivalent to K 0 and is 
dominated by M 0 , so it is given a weight 
of 2 and marked dominated by M 0 . 

Table 4 shows the complete fault graph 
(step 1), starting from the CF set and 
implemented in array form. 

We now reduce the fault graph (step 2) 
by compressing all equivalent faults into 
one and giving the new fault the sum of the 
equivalent weights. In this example C 0 , 
Do, F 0 , and G 0 can be reduced to C 0 with 
a weight of 11. Note that steps 1 and 2 can 
be performed simultaneously; that is, the 
graph can be reduced as it’s being built. 
This also allows us to reduce the size of the 
collapsed-fault set we will simulate. 

We now simulate the circuit with the test 
patterns (step 3), which in this case are 
exhaustive, and with the collapsed faults 
in level 1 of the fault graph. We mark off 
the detections, and the resulting fault 
graph is shown in Table 5. Note that if any 


of the detected faults had dominating 
faults on subsequent levels of the fault 
graph, these would have been marked as 
detected also. In this way a detected fault 
on the upper level can prevent the explicit 
simulation of faults on lower levels. At this 
point the CF coverage is 55.55 percent 
00, and the SSF coverage, calculated by 
adding the weights of the detected CFs and 
dividing by the total number of SSFs, is 
57.69 percent (%). 

We now generate a new collapsed-fault 
set consisting of Ey, M 0 , and J 0 (step 4), 
since these faults are undetected and dom¬ 
inate the undetected faults in the previous 
fault set. This is to ensure that no masking 
of detected faults occurs. We simulate the 
circuit with the same test patterns and this 
new fault set. We detect J 0 and M 0 but not 
Ei. The only fault to dominate E ] is Jo, 
but it has been detected already, so our 
simulation is finished. Table 6 shows the 
final fault graph. 

We calculate SSF coverage by adding 
the weights of the detected faults and 
dividing by the total SSF weight of the cir¬ 
cuit (step 5). For this example we have 

Ao + Bo+ Co + Ay + By+ Mo + Jo 
= 1 + 1 + 11 + 1 + 1 + 1+2=18 

This gives us the true SSF coverage of %, 
or 69.23 percent, which is very different 
from the 55.55-percent coverage reported 
for the collapsed faults. 

Note that for this small example circuit 
it would be better to avoid a multipass 
simulation by instead simulating all faults 
in the reduced fault graph during the first 
pass. This saves the cost of an additional 
good-circuit simulation. However, for a 
large circuit, the levels of the fault graph 
are apt to contain a large number of faults. 
In this case it saves time to perform a mul¬ 
tipass simulation, since many of the faults 
on the lower levels will dominate detected 
collapsed faults and therefore can be 
marked as detected without being 
explicitly simulated. 


Experimental results 

We applied procedure 1 to 10 combina¬ 
tional benchmark circuits 12 (the ISCAS, 
or International Symposium on Circuits 
and Systems, circuits) with 256 random 
patterns as test vectors. The circuits were 
simulated on a Sun-3 with a concurrent 
fault simulator 13 of our own design. 
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Table 7. Simulation of ISCAS circuits. 


Circuit 

Name 

Faults 

CF 

Cov. 

True SSF 

Faults Cov. 

Cov. 

% Error 

DL(Y= 0.5) 

Overhead 

Preproc. (s) Simul. (%) 

c95 

95 

0.9474 

204 

0.9755 

-2.88 

112.6 

0.020 

0.0 

c432 

519 

0.9403 

1,064 

0.9502 

-1.04 

19.5 

0.020 

2.1 

c499 

938 

0.9638 

1,302 

0.9555 

0.87 

-18.4 

0.040 

0.0 

c880 

785 

0.9427 

2,344 

0.9514 

-0.91 

17.5 

0.040 

6.0 

cl355 

1,250 

0.8952 

3,302 

0.9210 

-2.80 

31.5 

0.060 

0.0 

cl 908 

1,799 

0.8455 

4,822 

0.8548 

-1.09 

6.1 

0.120 

1.9 

c2670 

2,621 

0.8058 

7,308 

0.8032 

0.32 

-1.2 

0.180 

12.5 

c3540 

3,303 

0.8547 

9,316 

0.8782 

-2.68 

18.3 

0.260 

0.5 

C5315 

5,046 

0.9645 

13,750 

0.9759 

-1.17 

46.7 

0.360 

2.3 

C7552 

7,140 

0.9006 

19,730 

0.9132 

-1.38 

14.0 

0.540 

10.0 


Table 8. Two simulations of circuit c2670. 


Pass 

Faults 

Cumul. SSF Coverage 

Cumul. Sim. Overhead 

1 

2,621 

80.24% 

0.0% 

2 

128 

80.28% 

6.3% 

3 

5 

80.30% 

9.4% 

4 

2 

80.32% 

12.5% 

1 

2,621 

80.24% 

0.0% 

2 

143 

80.32% 

6.4% 


Table 9. Two simulations of circuit c7552. 


Pass 

Faults 

Cumul. SSF Coverage 

Cumul. Sim. Overhead 

1 

7,140 

91.22% 

0.0% 

2 

133 

91.31% 

7.2% 

3 

1 

91.32% 

10.0% 

1 

7,140 

91.22% 

0.0% 

2 

149 

91.32% 

7.4% 


Table 7 shows the results. The additional 
runtime required to calculate the true SSF 
coverage has been divided into preprocess¬ 
ing and simulation overhead. The 
preprocessing overhead includes the build¬ 
ing of the fault graph and the insertion of 
additional faults between passes. The 
simulation overhead is the time spent on 
the additional simulation passes shown as 
a percentage of the time spent simulating 
the original CF set. Normally, simulators 
would just simulate with the original CF 
set and stop there. 

The results shown in Table 4 demon¬ 


strate that the increased accuracy in fault 
coverage is significant and that the 
collapsed-fault coverage is not always a 
pessimistic underestimate of the true SSF 
coverage. The optimistic coverage for cir¬ 
cuit c499 is probably due to its having 
many XOR gates with easily detectable 
faults of SSF weight 1. Since the 
undetected faults have a higher SSF 
weight, the CF coverage gives an optimis¬ 
tic estimate of the true SSF coverage. 

The preprocessing overhead is negligi¬ 
ble, and the simulation overhead averages 
only 3.5 percent for these circuits. Circuits 


c2670 (12.5 percent) and c7552 (lOpercent) 
have relatively high simulation overheads. 
There are two reasons for this: 

(1) The faults simulated in additional 
passes of these circuits happen to be faults 
that cause a great deal of faulty-circuit 
activity. This makes the multipass simula¬ 
tions quite slow relative to the original CF 
simulation, considering the smaller size of 
the fault set. 

(2) Good-circuit simulation, repeated 
for every pass in the procedure, is costly. 

This caused us to consider a trade-off 
between the number of passes and the 
number of faults simulated. If we alter our 
procedure somewhat so that when we get 
to a certain level in the fault graph we 
simulate all faults below that level rather 
than continuing the multipass operation, 
we avoid repeating the good-circuit simu¬ 
lation. Of course, we have to simulate 
more faults this way because we may have 
been able to mark faults on the lower levels 
as detected without explicitly simulating 
them, if they dominated detected faults on 
higher levels of the fault graph. We modi¬ 
fied the algorithm by adding a simple test 
after each pass to verify that the number 
of faults on the lower levels of the fault 
graph was not below 20. The choice of 20 
was somewhat arbitrary and can certainly 
be altered. If the number of lower level 
faults was less than 20, we simply simu¬ 
lated those faults during the current pass. 
This saves multiple good-circuit simula¬ 
tions but increases the number of fault 
simulations. 

Tables 8 and 9 show the effect of this 
pass reduction on circuits c2670 and c7552. 
Note that in both cases the simulation 
overhead decreases even though the num¬ 
ber of simulated faults increases. Table 8 
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shows the result of reducing the number of 
passes for c2670 from four to two. The 
simulation overhead decreases from 12.5 
percent to 6.5 percent, for a 48-percent 
reduction in overhead. Table 9 shows the 
result of reducing the number of passes for 
c7552 from three to two. The simulation 
overhead decreases from 10 percent to 7.4 
percent, for a 26-percent reduction in over¬ 
head. This indicates that modifying the 
procedure to reduce the number of addi¬ 
tional passes will significantly reduce the 
extra simulation time for some circuits. 


W e have emphasized that 
collapsed-fault coverage is not 
equivalent to single-stuck- 
fault coverage, and we used Williams and 
Brown’s defect-level model to show that 
this difference significantly affects the 
projected defect level. True SSF coverage 
must take the SSF weights of the CFs into 
account, as well as possible masking of 
detected SSFs by undetected CFs. We 
presented a procedure to calculate true 
SSF coverage while allowing multipass 
simulation with reduced fault sets. We 
applied this procedure to the ISCAS cir¬ 
cuits and showed that it significantly 
increases coverage accuracy at a reasona¬ 
ble cost in simulation runtime. The simu¬ 
lation cost can be reduced even more by 
reducing the number of passes. Even 
though fewer passes means simulating 
larger fault sets, this extra cost is offset by 
reducing the number of additional good- 
circuit simulations. 

Since this procedure is applicable to all 
circuits and fault models exhibiting 
equivalence and dominance properties, it 
could be applied to sequential circuits, for 
example. New rules for creating the fault 
graph would have to be applied according 
to the new techniques of finding domi¬ 
nance. This procedure allows fault simu¬ 
lators to report fault coverages on the basis 
of the same standard, thereby increasing 
the accuracy and usefulness of the fault- 
coverage figure of merit.□ 
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A Support Environment for 
Hardware Design for Testability 


Jill J. Hallenbeck, James R. Cybrynski, 

Nick Kanopoulos, Tassos Markas, and Nagesh Vasanthavada 
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S ystem testability and diagnosabil- 
ity are two of the most important 
factors contributing to system life- 
cycle cost. System testability affects the 
cost of prototyping and production testing 
and is very closely related to system relia¬ 
bility. Reliability is generally defined as the 
conditional probability that a system is 
operational at time t, given that the system 
was fault free at time t = 0; therefore, the 
higher the confidence that the system was 
fault free at t = 0, the more realistic its 
predicted reliability. High confidence that 
the system is fault free can be established 
only if the system is highly testable. 

Given that a system is known to be mal¬ 
functioning, the time and cost required for 
its repair are directly proportional to its 
diagnosability. Diagnosability is the ease 
with which a fault causing the malfunction 
of a system can be isolated to a particular 
system part. Low repair cost implies a 
short time to isolate a fault to a relatively 
small part of the system, which can be 
replaced quickly. Furthermore, short 
repair times increase system availability. 

System testability and diagnosability 
depend on the design of the system and on 
the test sets used to perform testing and 
diagnosis. It is important to emphasize, 
however, that irrespective of the resources 
(for example, computer time, test time, 
automatic test equipment capabilities) one 
can afford to allocate for test set develop- 



A new set of CAD 
tools helps designers 


meet test and 
diagnosis 

requirements as an 
integral part of system 
design—not as an 
afterthought. 


ment, the system design defines an upper 
limit on the degree of testability and diag¬ 
nosability that can be achieved in a given 
system. Therefore, the designer can 
directly affect a system’s degree of testa¬ 
bility and diagnosability by considering its 
test and diagnosis requirements as design 
requirements, not as test requirements 
decoupled from the design process, as 
designers often do today. To design for 
testability, the system designer must follow 
a methodology that addresses testability 


issues as part of the design process. CAD 
tools are now available to support such a 
design methodology. 

TEA (Test Engineer’s Assistant) is a 
CAD environment developed to provide 
the knowledge base and tools needed by a 
system designer for incorporating testabil¬ 
ity features into a design. TEA helps the 
designer meet the requirements of fault 
coverage and ambiguity group size. Fault 
coverage is defined as the percentage of 
faults that can be detected out of the popu¬ 
lation of all faults of a unit under test with 
a particular test set. Ambiguity group is 
defined as the smallest hardware entity in 
a given level of the system design hierarchy 
(that is, board, subsystem, and system) to 
which a fault can be isolated. The fault 
model implied throughout this article is the 
single, stuck-at fault model. 

TEA interfaces to commercially avail¬ 
able or prototype, beta-site tools to create 
an environment in which the designer can 
perform design capture, functional verifi¬ 
cation, design for testability, fault simu¬ 
lation, and test program generation for a 
particular automatic test equipment sys¬ 
tem. Specifically, TEA interfaces to the 
Architecture Design and Assessment Sys¬ 
tem (ADAS), 1 and, through ADAS, to 
the VHSIC hardware description language 
(VHDL), 2 and, through VHDL, to the 
Tester Independent Support Software Sys¬ 
tem (TISSS). 3 
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Capture system design 
Partition system 
Simulate system functionally 

—► Pick subsystem 

1 

—► Pick board 

l 

Remove untestable structures 


Add BIT for fault 
isolation capability 


Provide test interface 
to subsystem level 


Perform fault simulation to 
verify fault coverage 


Define system test interface 


Figure 1. System design methodology used by TEA. 


Figure 2. User’s roadmap through 
detailed design using TEA. 


TEA methodology 

The TEA system design methodology, 
depicted in Figure 1, addresses testability 
issues at all stages of design (preliminary, 
detailed, final) and at each level of the sys¬ 
tem hierarchy. The requirements analysis 
identifies goals for system designers. 
Hardware and software resources are 
identified during preliminary design. In 
contrast to traditional design practices, 
test resources are also determined at this 
stage in the TEA methodology. 

During detailed design, specific func¬ 
tions of system resources are identified and 
verified through simulation and checked 


against system requirements, including 
testability. Trade-offs are made at this 
point to ensure that system requirements 
are met. TEA aids the designer in identify¬ 
ing and implementing test resources and 
verifying that they will meet system test 
and diagnosis requirements. When a con¬ 
tinuous trade-off between requirements 
and system configuration is necessary, an 
iterative process produces an acceptable 
design. 

TEA tools, primarily used to support 
the detailed design phase, are used itera¬ 
tively to design testable subsystems com¬ 
posed of testable boards. This process is 
shown in Figure 2 as loops in the TEA 


methodology. 

TEA’S concept of a testable system 
design is illustrated in Figure 3. In this con¬ 
figuration a system is composed of a set of 
subsystems communicating through a sys¬ 
tem bus or mission bus. Each subsystem is 
composed of a number of boards com¬ 
municating through a subsystem bus dur¬ 
ing normal operation and through a test 
bus in test mode. Each board interfaces to 
the test bus through the maintenance node. 
The maintenance node receives test data 
and control information from the test bus 
and uses this information to initiate tests 
and receive test results by controlling the 
built-in test (BIT) structures on the board. 
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Subsequently the maintenance node 
reports this information through the test 
bus. 

The maintenance node can be a single 
chip and it can directly interface to stan¬ 
dard testability buses, such as element test 
and maintenance (ETM), test and main¬ 
tenance (TM), and joint test action group 
(JTAG) buses, 4 ' 5 or any other bus the 
designer incorporates for communicating 
test data to and from the board. Test data 
may be provided to the maintenance node 
from the test control unit (TCU), a sub¬ 
system used exclusively to provide test data 
for every unit under test in the system and 
to analyze test results. The TCU can be 
embedded in the system, or its function 
can be performed by automatic test equip¬ 
ment (ATE), which can interface to the 
system mission bus or to a system test bus 
if the latter is available. With this config¬ 
uration the user can perform system diag¬ 
nosis in the field and determine a failed 
component without removing any parts of 
the system because all test facilities can be 
accessed throughout the system hierarchy. 

To design a system that conforms to the 
configuration in Figure 3, the designer 
must select appropriate BIT structures and 
appropriate test bus interfaces that will 
allow access to units under test throughout 
the system hierarchy. Furthermore, after 
making these selections, the designer must 
verify that the required fault coverage and 
ambiguity group size are achieved with 
affordable hardware and/or performance 
overhead. The role of TEA is to help the 
designer incorporate testability features 
into the design to meet test and diagnosis 
requirements, to provide an environment 
that allows the designer to verify that these 
requirements are met, and to provide 
qualitative measures of the overhead 
incurred by features designed to meet these 
requirements. With a system designed by 
the TEA methodology, the test engineer 
can isolate system faults to a single mod¬ 
ule or board when the system is operating 
in the field and to an ambiguity group of 
n chips (where n is prescribed in the design 
requirements) when the faulty module or 
board is tested by itself in the laboratory 
or the factory. This capability is particu¬ 
larly attractive in terms of repair times and 
repair costs, and it supports the two-level 
system maintenance facility advocated for 
government systems. 6 

TEA tool set 

Figure 4 shows the inputs, outputs, and 
interconnections of the TEA tools, TEA 



databases, and interfaces to existing tools 
(ADAS, VHDL, and TISSS). The 
provided databases (design-for-testability 
guidelines, system requirements, BIT rec¬ 
ommendation guidelines, BIT techniques 
and overhead estimates, BIT module 
library) are shown as input to tools. The 
following paragraphs describe the tools in 
this design environment, with emphasis on 
the TEA tools. 

ADAS. The Architecture Design and 
Assessment System is a dataflow-based 
modeling and simulation environment that 
provides designers with qualitative and 
quantitative information about the perfor¬ 
mance of a system architecture executing 
a set of algorithms. ADAS’s hierarchical 
directed graph editor captures hardware 
designs at the block diagram level. 1 Fig¬ 
ure 5 shows a typical ADAS graph used as 
input to TEA. The nodes represent chips 
and the arcs are data or control paths. On 
the display screen, graph elements are 


shown in various colors to make identifi¬ 
cation straightforward. 

VHDL. The VHSIC hardware descrip¬ 
tion language has been fostered by the 
Department of Defense and adopted by 
the IEEE as a standard language for 
describing the behavior, structure, and 
timing of hardware designs. Supported by 
simulation tools, VHDL provides a stan¬ 
dardized environment for the specifica¬ 
tion, verification, and documentation of 
hardware designs. 

TISSS. The Tester Independent Support 
Software System is an engineering envi¬ 
ronment in which test vectors can be gener¬ 
ated and graded for a given design, and, 
based on testing specifications, test pro¬ 
gram sets can be generated for a given 
ATE system. 3 The test program sets are 
used to control the ATE system selected 
for testing the design with the test vectors 
generated for this purpose. The design of 
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Figure 4. The TEA system. 


the unit under test is described in VHDL, 
and TISSS provides for test generation and 
grading by means of fault simulations 
through an interface to HILO, a widely 
used logic and fault simulation program. 


TEA. The Test Engineer’s Assistant 
includes five newly developed tools: 

• design-for-testability guideline 
checker: identifies difficult-to-test 
structures and recommends alterna¬ 
tive structures that are more testable. 

• BIT recommendation: divides a 


board into ambiguity groups for fault 
isolation testing and recommends a 
class of BIT techniques for each 
ambiguity group. 

BIT overhead summary: calculates 
the approximate hardware overhead 
(test points, BIT support modules, 
additional I/O) associated with the 
implementation of a particular BIT 
technique. 

BIT placement recommendation: 
generates a new schematic of a board 
with a sample implementation of a 
selected BIT technique. 


system summary: itemizes the 
incremental hardware overhead 
attributable to added testability 
features. 


During a typical detailed-design sce¬ 
nario (Figure 2), the designer captures the 
design, starting at the board level, using 
the ADAS directed graph editor. Every 
leaf node in the graph is a chip with its own 
VHDL description, and pertinent connec¬ 
tions between chips are modeled in the 
graph. From this graphical representation, 
ADAS automatically generates a VHDL 
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description (behavioral and/or structural), 
which is used for functional simulation 
with a VHDL simulator. 

After the design has been functionally 
verified, the designer invokes TEA to 
incorporate testability features such as BIT 
into the design by running the TEA tools 
(discussed in greater detail in the follow¬ 
ing paragraphs). Then, the designer again 
uses the VHDL simulator to ensure that 
adding such features does not affect design 
functionality. Next, to verify that the 
design meets fault coverage requirements, 
the designer invokes TISSS tools to trans¬ 
late the VHDL description of the design to 
a HILO description and performs fault 
simulation in the HILO environment. 
Since this translation uses the structural 
description of the design, the fault cover¬ 
age results obtained are the best indicator 
of how testable the design is and also of the 
quality of the test vector set used. Upon 
obtaining satisfactory fault coverage 
results, the designer can use TISSS tools to 
generate test programs for an ATE system, 
supported by TISSS, to be used in testing 
the design. Several iterations of this sce¬ 
nario may be required to obtain a design 
that meets testability and diagnostic 
requirements with affordable hardware 
overhead. 

Four of the TEA tools are used in 
sequence: (1) design-for-testability guide¬ 
line checker, (2) BIT recommendation, (3) 
BIT overhead summary, and (4) BIT 
placement recommendation. The system 
summary tool should be used throughout 
the process. 

The design-for-testability guideline 
checker uses a database of commonly 
accepted design-for-testability rules 7 to 
identify hard-to-test structures in a digital 
board design. The design topology and 
functions are compared to the guidelines, 
and if any violations are found, a message 
is issued to the designer. On-line documen¬ 
tation and support facilities aid the 
designer in removing or replacing the iden¬ 
tified structures with more easily testable 
substitutes. An explanation of why a par¬ 
ticular structure is hard to test is also 
provided upon request. 

The guidelines are of two types: those 
that aid test pattern generation (Gl) and 
those that aid test pattern application and 
fault isolation (G2). The following are 
some examples: 

G1 - 01 Use flip-flops, counters, 
and shift registers with a 
Preset/Clear capability. 

G 1 - 0 2 Make Preset/Clear a pri¬ 


mary input or primary 
input controllable. 

G1 - 0 8 Make buried control lines 
primary outputs. 

G1 - 0 9 Make the output of all 
logic-redundant nodes a 
primary output. 

G1 -11 Terminate all unused 

device inputs and tristata- 
ble outputs. 

G1 -1 4 Avoid asynchronous logic. 

G1 -1 5 Avoid uncontrollable 
feedback. 

G 2 - 0 1 Make all on-board clocks 
primary input controllable. 

G 2 - 0 3 Break up long counter 
chains. 

G 2 - 0 4 Avoid mixed logic families 
on the same board. 

G 2 - 0 5 Limit chip fanout at test 
points to one less than the 
specified maximum. 

Twenty-two guidelines are now imple¬ 
mented in the tool. In addition, a software 
utility lets users install their own 
guidelines. 

When a testability guideline violation is 
found in the design, the user’s current view 
is updated to show the violation in con¬ 
trasting colors, and a report file is written 
showing the modules forming the violat¬ 
ing pattern and examples of how the vio¬ 
lation can be corrected. 

The design-for-testability guideline 
checker finds violations by looking for 
attributes and connectivity on the graph 
representing a board, using graph- 
traversal and pattern-matching proce¬ 
dures. Graph traversal is used so that many 
possible pattern variations can be matched 
with the general guideline patterns. 

In pattern matching, the guideline 
checker searches a database to identify 
node description attributes that are perti¬ 
nent to a given guideline. Guidelines are 
used strictly to identify testability- 
inhibiting factors and not to calculate con¬ 
trollability/observability values, as was 
recently proposed in a similar approach. 8 
This is because the assumption that 
SCOAP-like 9 controllability/observabil- 
ity values offer a quantitative measure of 
design testability is rarely applicable to real 
circuits. 10 

In addition to the analyze function just 
described, the design-for-testability guide¬ 
line checker provides both an identify and 
an explain function. The identify function 
allows the user to select particular 
schematic components (for example, all 
test point outputs), and those components 


are highlighted on the current view. The 
explain function allows the user to see all 
the on-line information available about a 
particular guideline, including its purpose 
(example: Avoid one-shots as delay ele¬ 
ments because of their tendency to drift 
and provide unreliable timing pulses) and 
alternative structures (example: Use coun¬ 
ters or timers instead of one-shots for 
delay elements). 

After difficult-to-test structures have 
been removed from a design, BIT can 
effectively be added. The next three TEA 
tools provide the BIT support functions. 
These tools communicate by updating the 
internal graph data structure. Each tool 
provides the user with reports of its recom¬ 
mendations and/or findings. 

The BIT recommendation tool is 
invoked to partition the graph represent¬ 
ing the design into ambiguity groups. The 
maximum size of an ambiguity group 
(AG) is a design requirement and is used 
as an input to the tool. The tool first iden¬ 
tifies all possible partitions of the graph for 
a given AG size. Upon identification of 
this solution space, the tool identifies opti¬ 
mum solutions. Optimum solutions are 
defined as solutions that, in addition to 
meeting the AG size requirement, can be 
implemented at lowest cost. Cost is a func¬ 
tion of the number of AG inputs and out¬ 
puts. Therefore, the optimum solution 
provided by this tool is a partition that 
meets the required maximum AG size, and 
the selected AG partition has the minimum 
number of inputs and outputs. Minimiz¬ 
ing AG I/O is directly related to minimiz¬ 
ing hardware overhead, because AG I/O 
must be monitored and/or controlled 
either through employment of test points 
or through BIT. The solutions provided by 
this tool are derived by means of a combi¬ 
nation of branch-and-bound and linear 
programming techniques. 

The tool’s algorithmic approach 
guarantees an optimum solution, but algo¬ 
rithm runtime can be excessive for highly 
connected graphs with many nodes (on the 
order of 50) and relatively large AG size 
requirements (greater than 5). The runtime 
in such cases can be significantly shortened 
by a heuristic approach that yields a near- 
optimal solution." This heuristic 
approach is not incorporated in the proto¬ 
type version of the tool, but it is currently 
under benchmarking to determine its per¬ 
formance in terms of closeness to the 
optimal solution and in terms of runtime. 

After the design partitioning into AGs 
is complete, the tool recommends a BIT 
technique for each AG. This recommen- 
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Figure 5. Doppler filter board schematic captured by ADAS. 



Figure 6. Results of design-for-testability guideline checker applied to Doppler fil¬ 
ter schematic. Chips that violate guideline are highlighted in blue. 


dation is based on the topology and the 
function of the circuit and the testability 
knowledge in the tool’s BIT database. 
Despite the recommendation, the designer 
can always select a BIT technique and 
investigate its effect on the design. The tool 
arrives at its recommendation of a BIT 
technique by matching attributes of the 
nodes in the AG (such as combinational 
circuit, adder, PLA) to a set of guidelines 
that relate these attributes to BIT tech¬ 
niques supported by the tool and known 
to be suitable for circuits exhibiting these 
attributes. Since the tool does not use 
inference or fuzzy logic to arrive at a rec¬ 
ommendation, for certain circuits a rec¬ 
ommendation may not be available. It 
should also be noted that the BIT recom¬ 
mendation tool does not guarantee a pri¬ 
ori the satisfaction of fault coverage 
requirements. Evaluating fault coverage is 
a step the user has to perform, within the 
tool environment, as will be discussed in 
the following paragraphs. What the tool 
provides, however, is an optimum parti¬ 
tion of the design so that faults can be iso¬ 
lated to the required AG size. 

TEA supports both on-line and off-line 
BIT techniques. The off-line techniques 
include the following deterministic, 
pseudorandom, and combinations of 
deterministic and pseudorandom test pat¬ 
tern techniques: 

• continuous test point monitoring, 

• test point monitoring with data com¬ 
pression, 

• board-level boundary scan, 

• scan-set, and 

• test pattern generation with data 
compression. 

On-line techniques include parity check¬ 
ing/generation and comparison of dupli¬ 
cated modules. 

Once the design is partitioned into AGs 
and a BIT technique has been recom¬ 
mended by the tool or chosen by the user, 
the BIT overhead summary tool calculates 
the hardware overhead needed to ade¬ 
quately implement the chosen BIT tech¬ 
nique. This tool has a database of the BIT 
support modules required for implement¬ 
ing the BIT techniques supported by the 
tool. The following are examples of the 
modules, which are coded in VHDL: 

• 8-bit equal comparator, 

• 9-bit parity checker/generator, 

• built-in logic block observer, 

• example maintenance node, 

• pseudorandom test pattern generator 

• linear-feedback shift register, 

• scan-set register, 12 and 

• test switch. 13 
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Test Engineer’s Assistant (TEA) Output Report 
ADAS/TEA version: PROTO.TYPE 
Graph: 

Current view graph: Doppler_filter_board 

Current view filename: Doppler.hwg 


Design-for-Testability Guideline Checker 
(DFT analyze) 

Where: 

Subsystem: 

signal-processor 

Board: 

Doppler 

Guidelines selected 
Gl-11 


Results: 

Gl-11 

Gl-11—To aid test pattern generation, all unused inputs should be terminated. 

During implementation, port ‘‘inport = 7” of node “U22,” 

port “inport =4” of node “U24,” port “inport = 5” of node “U24,” 

port “inport = 7” of node “U24,” port “inport = 5” of node “U28,” 

port “inport = 5” of node “U33,” port “inport = 5” of node “U38,” 

port “inport = 5” of node “U36,” port “inport = 5” of node “U25,” 

port “inport = 7” of node “U25,” port “inport = 6” of node “U5,” 

port “inport = 7” of node “U5,” port “inport = 4” of node “U10,” 

port “inport = 5” of node “U10” should be terminated. 


Fourteen violations were found. 


Figure 7. Design-for-testability guideline checker output report corresponding to 


The BIT placement recommendation 
tool uses the chosen BIT technique and the 
AG information derived by the BIT rec¬ 
ommendation tool to update the graph to 
show the addition of the BIT support mod¬ 
ules and/or test points. This tool provides 
a netlist, including the BIT modules, as 
output; it also automatically updates the 
design-representation graph to include the 
recommended BIT modules. The designer 
can then resimulate the design with the 
added BIT modules, using VHDL 
behavioral and/or structural descriptions 
of the overall design. This resimulation 
ensures that BIT insertion has not affected 
the design’s functional and/or timing 
characteristics. 

After establishing the functional cor¬ 
rectness of the design, the designer must 
verify that the chosen BIT technique meets 
fault coverage requirements. By invoking 
the TISSS tools, the designer can transfer 
a structural description of the design, 
including BIT, to the HILO environment, 
where fault simulation can be performed. 
The fault simulation results indicate 
whether or not the design provides the 
required fault coverage. If it does, the 
design is complete, and the designer can 
invoke TISSS again, with the fault- 
simulation test vectors, to obtain a pro¬ 
gram for the ATE tester. 

If, however, the fault coverage require¬ 
ment is not met, the designer must reiter¬ 
ate one or more aspects of the design. The 
options to be examined are (1) improve¬ 
ment of the test vector set, (2) selection of 
a different BIT technique, and (3) selection 
of different types of nodes and connec¬ 
tivity. When a selected option alters the 
design in a way that affects the original 
graph, the designer has to repeat the 
appropriate steps in the methodology. 

At any point in the TEA methodology, 
the user can “freeze” versions of the graph 
hierarchy to use as baselines or design 
checkpoints. In addition to aiding design 
documentation, the system summary tool 
measures any change in the graphs that 
contributes to design testability. 

TEA software utilities let the user 
include additional guidelines for identify¬ 
ing difficult-to-test structures, select spe¬ 
cial AGs, and obtain on-line instruction 
about user functions, tool databases, and 
tool outputs. TEA provides the user with 
a current color-schematic view of the 
design and a menu-oriented interface. 

The user can prompt the on-line user 
support system utility, which is part of the 
TEA user interface (Figure 4), to (1) 


graph in Figure 6. 


explain a tool’s response, (2) provide fur¬ 
ther guidance with a tool, (3) provide alter¬ 
native, functionally equivalent testable 
structures, and (4) provide more informa¬ 
tion about BIT modules and techniques. 
This utility is equivalent to having a hard¬ 
copy instruction manual and design-for- 
testability textbooks available at all times. 

The TEA tools were developed on a 
Microvax II/GPX running VMS 4.6. The 
tools and utilities described here support 
the current TEA prototype, which is in 
beta-site testing. 

Example use of TEA 

TEA tools were used to analyze the 
Doppler filter board of the Firefinder 


radar system developed by Hughes Air¬ 
craft. 13 The design entered into ADAS is 
shown in Figure 5. Each of the 37 chips on 
the board is identified as U n, where n is an 
integer. A part number (not shown) iden¬ 
tifies each chip’s function and manufac¬ 
turer. All the chips are off-the-shelf 
components with SSI and MSI complexi¬ 
ties and various functional characteristics. 

Figure 6 illustrates violations identified 
by the design-for-testability guideline 
checker. The graph is color-coded on the 
user’s display to show problem chips. The 
Gl-11 guideline, “Terminate all unused 
device inputs and tristatable outputs, ’ ’ was 
violated by chips U5, U10, U22, U24, U25, 
U28, U33, U36, and U38, as shown on the 
graph and listed in the output report in Fig¬ 
ure 7. Each of these chips has at least one 
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Figure 8. Doppler filter divided into 20 minimum-cost ambiguity groups of maxi¬ 
mum size 3. 


unterminated input, which makes the chip 
vulnerable to noise. The tool recommends 
termination of those inputs to either high 
or low logic levels (not shown in Figure 7). 

Figure 8 is the Doppler filter graph 
marked to show an optimum partitioning 
of the board into AGs of maximum size 3. 
An optimum partitioning implies a mini¬ 
mal number of total AG inputs and out¬ 
puts. This translates into the number of 
test points needed, for example, for the 
implementation of a continuous test- 
point-monitoring BIT technique. 14 For 
this graph configuration, 80 test points 
must be monitored to isolate a fault to any 
group of chips shown in the figure. 

Figure 9 is the output report of the BIT 
recommendation tool for this example. It 
shows that there are 320 possible partitions 
with the required AG size of 3, but the tool 
recommends the one that yields the 
smallest number of total AG inputs and 
outputs, informing the user of the number 
of points (80) that need to be monitored to 
achieve the required fault isolation. Fur¬ 
thermore, the tool recommends a pseudo¬ 
random BIT approach because most of 
the logic is combinational and becomes 
highly observable and controllable with 
the insertion of the recommended test 
points. 


Test Engineer’s Assistant (TEA) Output Report 
ADAS/TEA version: PROTO.TYPE 
Date/Time: Thu Nov 3 18:48:35 1988 
Graph: 

Current view graph: Doppler_filter_board 

Current view filename: Project:[TEA.JJH.Doppler]Doppler.hwg;3 


BIT Recommendation Tool 
(BRT) 

BRT will divide the nodes on subsystem “signaLprocessor,” 
board “Doppler” into ambiguity groups of size 3 or smaller. 
There are 320 possible ambiguity groups of size 3 or smaller. 
The Tag_name attribute has been set for the following nodes: 
ambiguity^group: nodes Jn_AG 
AG1: U1 
AG2: U6 
AG11: U2 


AG19: U8 
AG28: U4 
AG32: U5 

AG140: U16 U21 Ull 
AG291: U15 U20 U10 
AG198: U14U19U9 
AG174: U12 U17 U7 
AG146: U18 U23 U13 
AG5: U22 
AG14: U24 
AG22: U25 
AG201: U32 U37 U38 
AG240: U28 U29 U34 
AG 180: U27U31 U26 
AG107: U33 U39 
AG24: U36 
AG35: U3 

Total # of output lines = 80 

All groups to be tested pseudorandomly. 


Figure 9. BIT recommendation for Doppler filter. 
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The recommended BIT technique can 
be implemented as continuous test point 
monitoring with pseudorandom test vec¬ 
tors supplied at the board’s primary inputs 
or by employing BIT modules that can 
generate on-board test vectors. A main¬ 
tenance node is always recommended for 
inclusion in the board design to provide the 
necessary test interface to the next level of 
the design hierarchy (see Figure 3). The 
inclusion of the maintenance node is 
shown in the output report of the BIT 
overhead summary in Figure 10. 

BIT modules supported by TEA, such 
as built-in logic block observers 12 and test 
switches, 15 can be inserted at the recom¬ 
mended test point locations to implement 
the pseudorandom test pattern recom¬ 
mended by the tool. Both modules are 
included in the library of BIT modules 
(Figure 4) supporting TEA. Assessing the 
recommended BIT technique’s perfor¬ 
mance and its particular implementation 
requires fault simulation with the test pat¬ 
terns generated by these modules accord¬ 
ing to the TEA methodology discussed 
earlier. 

Fault simulation results for the Doppler 
filter design indicate that a fault coverage 
of 99.9 percent can be achieved with 200 
test vectors, assuming stuck-at faults at the 
pins of the chips. 15 When structural faults 
internal to the chips on the board are 
assumed, the obtained fault coverage is 
99.75 percent with 500 test vectors. In both 
cases the results are very favorable, com¬ 
pared to 96.11 percent fault coverage for 
pin-level faults and 83.93 percent for gate- 
level faults achieved by using 422 vectors 
generated manually for testing the original 
design. 13 


Test Engineer’s Assistant (TEA) Output Report 
ADAS/TEA version: PROTO.TYPE 
Date/Time: Thu Nov 3 18:48:35 1988 
Graph: 

Current view graph: Doppler_filter_board 

Current view filename: Project:[TEA. JJH.Doppler]Doppler.hwg;3 


BIT Overhead Summary 
(BIT_cost) 

Generating hardware overhead for subsystem “signaLprocessor,” board 
“Doppler” 

Counts for BIT technique “det_tp” 

0 scan-set modules 
0 testing switches 
OTPGs 

0 built-in logic block observers 
0 2x16 muxes 
0 4x16 muxes 
80 test points 

0 BIT module control inputs 
0 BIT module test outputs 
1 maintenance node 


Note to user: 

If the costs itemized here are excessive, consider fixing some of the ambiguity 
group partitions with AG-NAME and/or increasing ambiguity group size and 
rerunning BRT. 

A maintenance node has been added to the costs listed above. A maintenance 
node should be employed when: 

(a) a test bus is used on board and/or 

(b) BIT modules that interface to the maintenance node are used on board. 


Figure 10. BIT overhead summary for Doppler filter. 


T he TEA tools and interfaces to 
other existing CAD tools create 
an environment for aiding system 
design for testability and diagnostics. The 
following are the basic TEA functions: 

(1) identifying testability-inhibiting 
factors, 

(2) identifying board-level BIT tech¬ 
niques and structures to achieve fault iso¬ 
lation to the AG size specified, 

(3) assessing hardware overhead for 
incorporation of BIT structures into the 
design, 

(4) identifying locations for test points 
and/or BIT modules in the design, and 


(5) recommending test interfaces at all 
levels of the system design hierarchy. 
The TEA recommendations minimize or 
eliminate hard-to-test circuit features and 
add BIT to meet fault detection and isola¬ 
tion testing requirements. 

TEA is applicable to today’s designs 
because it does not depend on either the 
existence of scannable off-the-shelf parts 
or a highly structured-for-test design. TEA 
does, however, support standard test inter¬ 
faces and identifies scan chains when 
boundary scan is used with a JTAG 5 or an 
ETM 4 interface. With TEA and its inter¬ 
facing tools, commercial and government 
users can demonstrate that they can meet 


test and diagnosis requirements at a calcu¬ 
lated hardware cost. □ 
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April foolery 

New benchmark puts RISCs/CISCs on even footing 


John H. Wharton 

Applications Research 

One of the problems facing the com¬ 
puter industry is that of comparing 
Apples to VAXes. When machines have 
different architectures, instruction sets, 
and operating frequencies, it’s hard to 
tell which gives the most bang for the 
buck. One common CPU performance 
metric is MIPS (millions of instructions 
per second). A Macintosh II executes 
somewhere around 2.1 MIPS and a VAX 
11/780, approximately 2.4 MIPS. 

(Note: The MIPS count of the instruc¬ 
tions actually executed by the VAX, 
sometimes called “mips,” is unrelated to 
its mips execution rating, sometimes 
called “MIPS.” Thus the Mips R2000 
processor may execute nearly 25 MIPS, 
but only about 17.8 MIPS. Novices 
sometimes confuse these concepts.) 

The problem. MIPS ratings might 
look reasonable to hardware purchasing 
agents and upper-level managers, but 
real programmers quickly realize this 
benchmark only begs the question: 
“What’s an instruction?” Conventional 
CISC machines vary drastically in the 
functions they can perform in a single in¬ 


struction. Consider the range of perform¬ 
ance levels within a single manufac¬ 
turer’s product line. 

An Intel 80286 at 8 MHz executes ap¬ 
proximately 1.0 MIP, or million instruc¬ 
tions per. Each instruction, however, can 
include a memory-reference calculation 
throughout a 16-gigabyte range with 
three-part address components. It can 
also support a segmentation component, 
should anyone want to. A 12-MHz 8051 
can also sustain 1.0 MIP, but only for 
straight-line code. 8051 instructions are 
lucky to reach off-chip memory at all. 

The discrepancy in instruction com¬ 
plexities can only get worse as RISC 
machines become more popular. Some of 
the more exciting RISCs can execute 
blazingly many instructions, but the indi¬ 
vidual instructions themselves don’t do 
squat. A new benchmark metric is re¬ 
quired to avoid further confusion. In its 
April 1, 1988, issue. Microprocessor Re¬ 
port published its conclusions on how 
this benchmark should be designed. 

Mhoistone objectives. For simplicity, 
the new benchmark should be based on a 
single, unified program. To assure that 
the actual device performance (not the 
creativity of some hoity-toity optimizing 


compiler) is being measured, the pro¬ 
gram must be written in assembly lan¬ 
guage. And finally, a totally objective 
comparison of processor performance is 
only possible if the benchmark program 
can run unmodified on the range of sys¬ 
tem architectures to be compared. 

In practice, of course, the varying se¬ 
mantics of assemblers make the third ob¬ 
jective unattainable. However, a close 
approximation can be obtained if we al¬ 
low direct mechanical translation from 
one machine’s assembler syntax to the 
next. The key is to ignore all data ad¬ 
dressing modes and other architectural 
nuances of the various machines, such as 
whether they are Von Neumann or Har¬ 
vard architectures, and whether the CPU 
is accumulator, register, or stack cache 
based. In other words, this benchmark 
must not allow the CPU to perform any 
actual operations. 

The resulting program, therefore, may 
only use NOPs and simple, universal 
control-flow instructions such as Jump 
and Call. Performance, measured in 
Mhoistones, is simply the number of it¬ 
erations of the basic program loop that 
can be performed in one second. 

The proposed standard algorithm is 
shown in Figure 1, using various assem- 


MAIN: NOP 

MAIN 

NOP 

Main: 

nop 


NOP 


NOP 


nop 


NOP 


NOP 


jmpl 

dummy ,r31 

CALL DUMMY 


BSR DUMMY 


nop 


NOP 


NOP 


nop 


NOP 


NOP 


nop 


NOP 


NOP 


ja 

main 

JMP MAIN 


BRA MAIN 


nop 


DUMMY: NOP 

DUMMY 

NOP 

dummy: 

nop 


NOP 


NOP 


nop 


NOP 


NOP 


jmpl 

[r31]+8,r0 

RET 

* 

RTS 


nop 


(a) 

(b) 


(c) 




Figure 1. Mhoistone assembly-language implementations: (a) Intel; (b) Motorola; (c) Sparc. 
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bly language syntaxes. Figure la is suit¬ 
able for execution on all Intel processors 
introduced to date, from the 4004 to the 
80386. Figure lb covers the entire 
Motorola line, from the 6800 to the 
68030. 

Figure lc shows the algorithm as 
translated to the Sun Microsystems Sparc 
architecture. Sparc uses delayed branch¬ 
ing for all sequence control operations; 
note that execution was optimized by re¬ 
arranging the instruction stream to move 
preceding NOPs into all delay slots. 

Work in progress. Microprocessor 
Report is currently applying this bench¬ 
mark to several of the more popular mi¬ 
croprocessor architectures. Initial tests 
have revealed some rather surprising re¬ 
sults. When normalized for clock fre¬ 
quency, simple 8-bit machines compare 
quite favorably with their 16- and 32-bit 
counterparts. Sophisticated instruction 
prefetch queues actually seem to be a 


John H. Wharton 

Applications Research 

Engineers attempting to stay current 
with each new generation of the IBM 
PC, XT, AT, and respective clones have 
by now accumulated closets full of obso¬ 
lete systems. If the PS/2 and EISA bus 
systems catch on, that closet space will 
become even more precious. Micropro¬ 
cessor Report has evaluated a variety of 
PC add-in boards designed to rekindle 
the power left in those old gray boxes. 
Perhaps the most practical and creative is 
the PS/+ series recently introduced by 
Xanthrax Systems. The PS/+5 (see Fig¬ 
ure 1) is a clever half-size card that turns 
any IBM PC, AT, or compatible into a 
well-regulated 5-volt power supply. 

Installation of the board is straightfor¬ 
ward. In applications with moderate ex¬ 
ternal power requirements, Xanthrax rec¬ 
ommends that memory expansion cards 
and accelerator boards be removed and 
discarded. A custom decoder PAL sup¬ 
plied with the PS/+5 kit disables DRAM 
memory refresh on the motherboard, 
greatly reducing memory power con¬ 
sumption. If the internal power supply is 
still inadequate, as evidenced by thick, 
acrid fumes from the ventilation fan out¬ 
let, certain high-performance compo¬ 
nents on the motherboard, such as the 
CPU and math coprocessor, should be 
pried loose. 

The board comes with a clear, well- 
written manual. Chapter 1, “The Rising 
Cost of Iron,” explains why the initial 


hindrance. And vector processors don’t 
even begin to show the performance im¬ 
provements their marketing people 
would have you believe. 

The Mhoistone algorithm has been 
translated into C-language semantics, as 
shown in Figure 2, to determine the ex¬ 
tent to which compiler-generated code 
slows execution speed. Unfortunately, 
the technicians were unable to complete 
these tests; the compiler at its highest op¬ 
timization level determined that the en¬ 
tire program was extraneous, collapsed it 
into nothingness, and eliminated it from 
the executable instruction stream. 

This reduces its execution time to 
zero, which implies a Mhoistone rating 
of infinity. Clearly this is not possible; 
it’s well known that compiler-generated 
code can never be faster than the assem¬ 
bly language equivalent. Readers should 
be wary of higher compiler optimization 
levels until the vendors are able to fix 
this blatant code-generation problem. 


in old PCs 

purchase of a PC has become a strategic 
investment. Chapter 3, “Gutting the Sys¬ 
tem,” explains how to remove other add¬ 
in boards and ICs and is written in lan¬ 
guage clear enough to assure even a lay¬ 
person that the damage inflicted on the 
motherboard will not affect power supply 
operation. 

Chapter 6, “Micro Optimization,” ex¬ 
plains how to use a can of aerosol spray 
paint to locate the hottest (and therefore 
most power-hungry) components on the 
board. There are also several appendixes 
for the more technically-minded (“The¬ 
ory of Application of the Crowbar” is 
quite informative). 

The product is well thought-out; the 
cardboard box in which the board is 


main() 

I 

for (;;) 
{ 


dummy!); 


} 

I 

void dummy() 
{ 


) 


Figure 2. Mhoistone C-language im¬ 
plementation. 


shipped can even be inserted into the PC 
to displace dead air over the mother¬ 
board, where other add-in boards used to 
be. This directs more air flow from the 
cooling fan through the internal power 
supply. 

The basic PS/+5 sells for $325 in 
quantity one and comes with a pair of di¬ 
agonal cutters and a small chisel. Future 
products include the PS/+512 (dual 5- 
and 12-volt supplies) for $415 and the 
deluxe model PS/+512-12, intended for 
analog system designers. Similar designs 
are expected soon for the Apple II and 
non-68030-based Macintosh SE and II. 

For more information, contact Xan¬ 
thrax Systems, PO Box 2038, Sunnyvale, 
CA 94087, phone (408) 773-1575. 



Add-in board taps power latent 
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Conference Registration Form 

Send form or facsimile to: Conference Department, 9th ICDCS, IEEE Computer Society, 1730 
Massachusetts Avenue, NW, Washington, DC 20036-1903, Phone Number (202) 371-1013, 
Fax Number (202) 728-9614. Make check payable to ICDCS-9. 




Mailing Address 


City/State/Zip/Country 

Work Phone IEEE Membership Number 

Do not include my mailing address on: □ Non-society mailing lists □ Meeting attendee lists 
TUTORIALS: Please check the Tutorial(s) you wish to attend 

□ Tutorial 1: Fault Tolerant Computation 
Monday, June 5, 1989 

□ Tutorial 2: Concurrency and Coherency Control for Multi-System Transaction Processing 
Monday, June 5, 1989 

□ Tutorial 3: Parallel Processing Networks and Systems 
Friday, June 9, 1989 

□ Tutorial 4: Distributed Database Management Systems 
Friday, June 9, 1989 

CONFERENCE REGISTRATION FEES (please circle appropriate fees) 

Advance Registration Fees—Until May 8,1989 

Conference Only: 

Members = $210.00 Nonmembers = $265.00 Students = $60.00 
Tutorials Only: 

Members = $160.00 per tutorial Nonmembers = $200.00 per tutorial 
Students = $160.00 per tutorial 

Registration Fees—After May 8,1989 

Conference Only: 

Members = $250.00 Nonmembers = $315.00 Students = $70.00 
Tutorials Only: 

Members = $190.00 per tutorial Nonmembers = $240.00 per tutorial 
Students = $190.00 per tutorial 

Note: The tutorial fees are per tutorial and are not included in the conference registration fee. 
The conference reserves the right to cancel any tutorial which lacks sufficient interest. 
Notification of any changes to the schedule will be made as the need becomes evident. 

Total Enclosed: $- 

Method of Payment 

□ Personal Check □ Company Check □ VISA □ MasterCard □ American Express 

Card Number ~ Exp. Date 


Signature 

Registration fee includes the proceedings and reception. Written requests for refunds must 
be received in the Computer Society Office not later than May 22,1989. Refunds are subject 
to a $15 processing fee. 


Accommodations 


The International Conference on Distributed Computing Systems conference is headquartered at the Newport Beach Marriott 
Hotel, 900 Newport Center Drive, Newport Beach, CA 92660 where all conference sessions will be held. Special room rates of 
$99.00 per day are available for conference attendees until May 14,1989. After May 14,1989 reservations will be accepted 
on a space available basis, therefore to assure a room at the Marriott Hotel, early booking is advised. Make reservations directly 
with the hotel, either by telephone (800) 228-9290 or (714) 640-4000 or by mail. 

Local Information 


The city of Newport Beach is situated mid-way between Los Angeles and San Diego in the heart of beautiful Orange County. Its 
almost 365 days a year of near-perfect weather makes it one of the most attractive vacation spots on the Pacific coast. The 
following is a partial list of sights within a short driving distance: 

■ Balboa Island (10 min) ■ Anaheim Stadium (25 min) 

■ Orange County Performing Arts Center (15 min) ■ Queen Mary/Spruce Goose (Long Beach Harbor) (40 min) 

■ Disneyland (25 min) ■ Los Angeles County Museum of Art (60 min) 

■ Knott's Berry Farm (25 min) ■ Chinatown (60 min) 

■ Laguna Beach (25 min) ■ Universal Studios and Hollywood (80 min) 

■ San Juan Capistrano Mission (25 min) 
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“SES NEWS 


Editor: Sallle Sheppard, Office of Associate Provost for Honors Program and Undergraduate Studies, Texas A&M University, College Station, TX 77843; (409) 845-3210 


Poduska, Bauer, Hoff receive high Computer Society honors 


Presentation of the 1988 W. Wallace 
McDowell Award, the IEEE Computer 
Society’s premier technical achievement 
tribute, plus two 1988 Computer 
Pioneer Awards, topped the array of 
society honors presented during three 
awards events March 1 at Compcon 
Spring 89 in San Francisco. 

J. William Poduska, Sr., founder of 
Prime Computer and Apollo Computer 
and the current chairman and CEO of 
Stellar Computer, was presented the 
McDowell Award. 

The Computer Pioneer Awards went 
to Friedrich L. (Fritz) Bauer, who is in 
his final year as professor at the Institut 
fur Informatik at the Munich Univer¬ 
sity of Technology before he retires in 
July, and to Marcian E. (Ted) Hoff, 

Jr., an independent consultant who was 
formerly with Intel and Atari. 

The society also presented the inau¬ 
gural Taylor Booth Award to James T. 
(Tom) Cain of the University of Pitts¬ 
burgh (see Computer, January 1989, p. 
105). 

A Cray Research research team led by 
Phuong Vu won the second annual Gor¬ 
don Bell Prize of $1,000 in a contest 
sponsored by Bell of Ardent Computer 
and administered by IEEE Software 
(see Computer, March 1989, p. 76). 

IEEE fellow certificates were 
presented to Jon T. Butler, Bill D. Car- 
roll, Alexander G. (Sandy) Fraser, 

Egon E. Loebner, and Alan J. Smith 
(see Computer, March 1989, pp. 74-75). 


Fraser was also recognized with the 
IEEE 1989 Koji Kobayashi Computer 
and Communications Award. In addi¬ 
tion, a number of awards were 
presented for Computer Society service. 

In winning the McDowell Award, 
Poduska was cited for his “continued 
creative contributions to hardware and 
software developments and for manage¬ 
ment expertise in bringing them to 
products.” Poduska is an IEEE fellow 
and a member of the National Academy 
of Engineers. Just prior to receiving the 
award, Poduska delivered an invited 
Compcon address entitled “Visualiza¬ 
tion with Graphics Supercomputers.” 

The McDowell Award, bearing the 
name of the late IBM vice president 
since'presented for the first time in 
1966 thanks to an IBM grant, carries 
with it a $2,000 cash prize. 

In commending the two 1988 Com¬ 
puter Pioneers, the Computer Society 
cited Bauer for developing the first 
hardware computer stack and Hoff for 
developing the concept and architecture 
for the first microprocessor on a chip. 
The Computer Pioneer Award is 
presented to outstanding individuals 
whose principal contributions to early 
concepts and development in the com¬ 
puter field were made 15 or more years 
ago. 

With Klaus Samelson, Bauer devel¬ 
oped the concept, implementation, and 
utilization of the stack principle for 
algebraic formula translations. Bauer 


was also one of the 13 originators of 
Algol60. 

Hoff, an IEEE fellow, proposed a 
single-chip general-purpose central 
processor while with Intel. The concept 
led to Intel’s first microprocessor 
family, the MCS-4, and to the 8008 and 
8080 architectures. 

IEEE President-elect Carleton Bay¬ 
less presented the Kobayashi Award 
and an accompanying $2,000 check to 
Fraser “for contributions to computer 
communications and the invention of 
virtual-circuit switching.” Fraser is 
executive director of the Research Infor¬ 
mation Sciences Division of AT&T Bell 
Laboratories. 

The award salutes Koji Kobayashi, 
who has been a leading force in advanc¬ 
ing the integrated use of computers and 
communications. It is sponsored by 
NEC America and NEC Information 
Systems through the IEEE Foundation. 

Achievement, service kudos. A Com¬ 
puter Society Outstanding Contribution 
Certificate was presented to Paul Hazan 
“for successful definition, develop¬ 
ment, and delivery of the society’s first 
satellite symposium, Compusat 88” (see 
Computer, August 1988, p. 77; Septem¬ 
ber 1988, p. 73; and January 1989, pp. 
130-131). 

Meritorious Service Certificates were 
presented to the following: 

• Jon T. Butler for “dedicated service 
as editor of IEEE Transactions on 
Computers, 1984-1986, and for innova¬ 
tive leadership as vice chair of the soci¬ 
ety’s Technical Activities Board.” 

• Luis-Felipe Cabrera for “repeated 
contributions to the Technical Commit¬ 
tee on Operating Systems and the 
Workshop on Workstation Operating 
Systems, 1987-88.” 

• Paul I. Davis for “coordinating and 
expediting Committee on Public Policy 
activities as secretary/treasurer, 

1984-87, and as vice chair, 1988.” 

• Alicja I. Ellis for “significant con¬ 
tributions to chapter activities, 

1986-88.” 

• Wing N. Toy for “contributions to 
the Computer editorial board, 1984.” 

Certificates of Appreciation were 
presented to: 

• Micha Avni for “contributions to 


Nominations sought for second Booth Award 


James T. (Tom) Cain, who won the 
first IEEE Computer Society Taylor 
Booth Award for outstanding contri¬ 
butions to improving computer 
science and engineering education, 
is chairing the committee seeking 
nominees for this year's Booth 
honoree. 

The award takes into account each 
nominee’s achievement as an 
instructor, text author, curriculum 
developer and model providing inspi¬ 
ration to others. 

It honors the late Taylor L. Booth, 


who was director of the Computer 
Applications and Research Center 
and professor of computer science 
and engineering at the University of 
Connecticut. 

Established in 1988, the Booth 
award includes a $2,000 check, a 
plaque and brochure, and covers up 
to $1,000 in travel expenses. 

Nominations for this year’s Taylor 
Booth Award should be sent to 
James T. Cain, University of Pitts¬ 
burgh, 348 BEH, Electrical Engineer¬ 
ing, Pittsburgh, PA 15261. 
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Claud Davis (left), Computer Society 
Awards Committee chair, presented the 
1988 McDowell Award to Bill Poduska 
during March 1 Compcon Spring. 


Ted Hoff (center) and Fritz Bauer (second right) were presented 1988 Computer 
Pioneer Awards. Helping mark the occasion at the Compcon awards luncheon 
were Ed Parrish (left), Helen Wood, and Ken Anderson (right), the society’s 
respective past president, president-elect, and current president. 



The Computer Society’s Sandy Fraser, Egon Loebner, Jon Butler, Alan Smith, and 
Bill Carroll (from left) received their IEEE fellow certificates at the luncheon. 
Fraser was also presented the 1989 Koji Kobayashi Computer and Communications 
Award at Compcon. 


Taylor L. Booth’s widow, Aline, made 
the Taylor Booth Award presentation 
to Tom Cain (left) after her introduc¬ 
tion by Gerald Engel, the society’s vice 
president, education. 



Substituting for her husband, who was ill, Mrs. Gordon Bell 
presented the second annual Gordon Bell Prize to a Cray 
Research team made up of (from left to right) John Lewis, 
Phuong Vu, Roger Grimes, Horst Simon, and (not present) 
Cleve Ashcraft and Barry Peyton. 



Richard Frary (left) received a Certificate of Appreciation; 
Paul Hazan (second left), an Outstanding Contribution Cer¬ 
tificate; and Paul Davis (second right) and Wing Toy, 
Meritorious Service Certificates at the luncheon. 
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chapter activities, 1987-88.” 

• Richard S. Frary for “timely 
reporting and incisive views on 
computer-related policy formulation as 
the Committee on Public Policy’s 
Washington coordinator, 1985-88.” 

• Michel Israel for “contributions to 
chapter activities in Region 8.” (Israel 
was not in attendance, but will receive 
his certificate at a future session.) 

Compusat honors. Carol M. Daly 
was named Compusat Person of the 
Year for obtaining the highest number 


of Compusat 88 receiving sites. She 
obtained six sites on her own and 
assisted with 20 to 25 others. 

The following earned Technical 
Activities Board Compusat Pioneer 
honors for “distinctive service on the 
Compusat 88 production team from 
February through October 1988”: 
Jacob A. Abraham, Jake K. Aggarwal, 
Kenneth R. Anderson, Donald W. 
Bouldin, Jon T. Butler, Christina 
Champion, Carol M. Daly, Lorraine 
M. Duvall, Michael Evangelist, 
Christine Hall, Harry Hayman, Paul 


Hazan, Camie Jackson, Robert G. 
Kahrmann, Laurel V. Kaleda, Betty 
Maranca, Raymon P. Oberly, David C. 
Rine, Tom Rutenbeck, Stephen R. 
Ruth, Merlin G. Smith, Mohan M. 
Trivedi, Nicolas Vogel, Anneliese von 
Mayrhauser, Ronald Waxman, and 
Thomas W. Williams. 

In addition, Robert Poston and Ber¬ 
nard T. O’Lear were presented TAB 
Pioneer honors, Poston for service on 
the CASE Tools Task Force and O’Lear 
for service on the Global Change Task 
Force. 


Board of Governors approves launching new IEEE 


Sal lie Sheppard, Texas A&M University 

The IEEE Computer Society Board 
of Governors approved a proposed new 
IEEE Transactions on Parallel and Dis¬ 
tributed Computing at its meetings held 
in conjunction with Compcon Spring 88 
March 3 in San Francisco. IEEE 
approval will be sought at the May 
meeting of the IEEE Technical Activi¬ 
ties Board. 

The scope of the new transaction, 
scheduled to begin quarterly publication 
in January 1990, will include parallel 
and distributed architectures and soft¬ 
ware; parallel algorithms and applica¬ 
tions; and performance evaluation, 
modeling, and fault tolerance in paral¬ 
lel/distributed computing. 

The board recommended that Presi¬ 
dent Ken Anderson appoint Tse-Yun 
Feng of Pennsylvania State University 
as the first editor-in-chief. Feng served 
as editor-in-chief of IEEE Transactions 
on Computers from 1982 to 1986. His 
nomination was endorsed by the Publi¬ 
cations Board. 

Information on subscriptions can be 


obtained by circling reader service No. 

200 . 

President Anderson declared that 
1989 is the year of technical, educa¬ 
tional, and area activities for the soci¬ 
ety. To that end, Anderson said the 
focus for the year will be on the Techni¬ 
cal Activities Board (TAB), the Educa¬ 
tional Activities Board (EAB), and the 
Area Activities Board (AAB). 

Anderson noted that the meta objec¬ 
tive for 1989, “Be Number One,” was 
developed by the 1988 Planning Com¬ 
mittee (see the “President’s Message” 
in this issue) and endorsed by the Com¬ 
puter Society Executive Committee at 
its January meetings. 

An expanded set of objectives to 
accomplish the meta objective calls for 

• a full range of services appropriate 
to the membership 

• adapting to and keeping pace with 
changing technology 

• achieving and maintaining the 
highest quality in all programs 

• being the representative society of 


Orientation session for volunteers slated 


An orientation session providing an 
overview of the organization and opera¬ 
tion of the IEEE Computer Society will 
be held from 9 a.m. to noon, Tuesday, 
May 16. The program, sponsored by the 
society’s Technical Activities Board, 
will be held at the Vista Hotel in Pitts¬ 
burgh in conjunction with the Interna¬ 
tional Conference on Software 
Engineering. 

Laurel Kaleda, vice president for 
technical activities, is inviting all new 
volunteers associated with Computer 
Society technical committees, as well as 
others interested in further involvement 


in the society’s activities, to attend. 

The program will include presenta¬ 
tions by officers and staff members of 
the society, with descriptions of activi¬ 
ties and the opportunities for involve¬ 
ment open to volunteers. 

The relationship between the Com¬ 
puter Society and IEEE will also be 
explored. 

Persons planning to attend the orien¬ 
tation are being asked to notify Sherry 
Stanton in the society’s Washington, 
DC, headquarters at (202) 371-0101 to 
ensure that sufficient materials are 
available at the presentation. 


transactions 


computer professionals 

• maintaining financial viability 

• achieving recognition in the scien¬ 
tific/technical community 

TAB was featured at the San Fran¬ 
cisco meetings, with a reception honor¬ 
ing all those who worked on Compusat 
88, the successful 1988 satellite sympo¬ 
sium. Plans were unveiled to stage 
Compusat 89. 

Anderson announced the following 
appointments of special Presidential 
Advisors for 1989: 

• Transnational relations ambas¬ 
sador, Ed Parrish 

• Public relations advisors, Helen 
Wood, Ron Hoelzeman, James 
Aylor, and Willis King 

• Technology development and trans¬ 
fer director, Paul Hazan 

• Society and external relations advi¬ 
sor, Oscar Garcia 

• Public policy initiatives advisor, 
Ralph Preiss 

• Region 10 activities program advi¬ 
sor and director, Akihiko Yamada 

• Region 8 activities program advi¬ 
sor, Jacques Tiberghien 

• Region 1-6 activities program advi¬ 
sor, Ned Kornfield 

The 1988 year-end Computer Society 
membership figure of 100,579 (see 
Computer, February 1989, p. 80) was 
significantly higher than the year’s 
94,500 goal and represented an 11.5 
percent growth over year-end 1987. Of 
the total growth, student membership 
grew 16 percent, affiliate memberships 
33.7 percent, and full memberships 5.1 
percent. 

Merlin G. Smith, the 1988 vice presi¬ 
dent for membership and information 
activities, led the membership drive, 
with very able support from Christina 
Champion, Membership and Circula¬ 
tion Promotion Department manager. 


78 


COMPUTER 








Digital Cellular Radiotelephone Systems 


At Motorola Cellular, we keep in tune with new tech¬ 
nological advancements through the talent and drive 
of our professionals. 

Our revolutionary Digital Cellular Radiotelephone 
Systems exemplify the phenomenal breakthroughs in 
ODject-oriented design using C++, advanced data 
protocols, a CASE/CAE environment, ASIC design, 
advanced error coding and encryption methodology, 
to name a few. 

We are seeking performers who want to orchestrate 
their own future and the future of cellular technology. 
The following opportunities are currently available: 

SOFTWARE ENGINEERS: Minimum of two years ex¬ 
perience in any one of the following: UNIX* C and 
assembly languages; Al/Expert Systems; ISDN; 
Advanced Communication Networks; Object-orien¬ 
ted Design using C + +; Common Channel Signaling 
System No. 7; Advanced Data Communication 
Protocols; CASE Environment; Encryption; Packet 
Switching (X.25). 


COMPUTER ENGINEERS: Two or more years 
experience in any of the following: DSP; ISDN; 
Advanced Data Communication Networks; Ad¬ 
vanced Data Communication Protocols; ASIC Design; 
CASE/CAE Environment; Encryption; Digital 
Modulation; Speech Coding; Advanced Error Cor¬ 
rection Coding; Packet Switching (X.25); Digital 
Mobile Communication; Channel Equalizers. 

Motorola offers the “chance of a lifetime" to compose 
a system of major scale. Join the undisputed leader 
of cellular technology. For consideration, forward 
your resume to: Professional Staffing, Dept. 
#CO390, Motorola, Inc., Cellular Group, 1501 
West Shure Drive, Arlington Heights, IL 60004, 
or FAX your resume to: (312) 632-5717. Equal 
opportunity/affirmative action employer. 

(M MOTOROLA INC. 

^ Cellular Group 


AND 






UPDATE 


IEEE-USA releases federal R&D budget report 


The IEEE United States Activities 
March 8 released Electrotechnology in 
the FY 1990 Research and Development 
Budget , a 10-page document describing 
proposed 1990 R&D budgets for electri¬ 
cal and electronics technology used in 
the Defense and Energy Departments, 
NASA, the National Science Foundation, 
and the National Institute of Standards 
and Technology in the Commerce De¬ 
partment. 

Highlights of the report, prepared by 
William G. Herrold on behalf of the 
IEEE-USA Technology Activities Coun¬ 
cil, include: 

• NIST would receive $155.6 million, 
including $3.5 million additional to im¬ 
plement the Computer Security Act of 
1987, $2.6 million additional to provide 
measurement technology and services for 
the components of fiber optics systems, 
and $700,000 additional for high-tem- 
perature superconductors. 

• A 14 percent increase has been pro¬ 


posed for NSF for a total of $2,149 bil¬ 
lion. The largest increase would go to the 
Computer and Information Science and 
Engineering Directorate, with emphasis 
on VLSI computers and prototyping, 
computer vision and speech, software 
systems and engineering, and various 
networking projects. 

• The Defense Advanced Research 
Projects Agency would receive $1.12 bil¬ 
lion, a reduction of 12.9 percent. 

• Total funds proposed for the Army’s 
Research, Development, Test, and Evalu¬ 
ation (RDT&E) are $5.6 billion for 1990, 
more than 9 percent over 1989. The 
Navy’s RDT&E program would grow 9 
percent to almost $10.2 billion in 1990. 
Air Force RDT&E would receive $14.8 
billion, less than 1 percent over 1989. 

• Funds allocated to the Strategic De¬ 
fense Initiative Organization would in¬ 
crease 54 percent to $5.59 billion. 

• NASA R&D would increase 35 per¬ 
cent to $5.75 billion, with a total NASA 


budget of $13.3 billion. The major 
beneficiary would be the space station 
program, with an increase from $1.15 
billion to $2.05 billion. 

• Basic research in the Energy Depart¬ 
ment would increase 57 percent to $1.17 
billion, with the largest increase ear¬ 
marked for the Superconducting Super¬ 
collider (150 percent, to $250 million in 
1990). 

• The Energy Department’s clean coal 
technology program would receive ad¬ 
vanced appropriations of $710 million 
for 1990 through 1992. The nuclear en¬ 
ergy budget would remain almost con¬ 
stant at $352 million. Renewable energy 
research and development, budgeted at 
$114 million, would be reduced 24 per¬ 
cent. 

Copies of Electrotechnology in the FY 
1990 Federal R&D Budget are available 
from the IEEE-USA Office, 1111 19th 
St. NW, Suite 608, Washington, D.C. 
20036, phone (202) 785-0017. 


Computer literacy top priority for industry-supported foundation 


Computer Literacy Month has become 
a year-round campaign to promote com¬ 
puter literacy in North America with the 
establishment of the Computer Learning 
Foundation. Supported by major soft¬ 
ware publishing companies, as well as 
Apple, IBM, Tandy, and Commodore in 
1988, CLF expects to receive up to $1 
million in funding this year. 

CLF’s announcement coincided with 
predictions of a national technological 
decline touched off by an Educational 
Testing Service study that showed 13- 
year-old US students scoring the lowest 
in an international comparison of mathe¬ 
matics and science skills. Earlier, a Na¬ 
tional Research Council study reported 
that American students were being “left 
behind” due to a mathematics teaching 
system that set its expectations too low. 

Last October’s Computer Literacy 
Month program reached more than 60 
million people and was the catalyst for 
nearly 3,000 events in schools and cities 
throughout the US and Canada. This 


year’s events offer a variety of programs 
and materials designed to reach millions 
of children, adults, and educators. CLF 
will publish and distribute books that ad¬ 
dress computers and careers, and school 
lesson plans for all age ranges and edu¬ 
cational levels. The foundation will also 
distribute posters and Computer Learn¬ 
ing Month event kits to schools and com¬ 
munity groups to support their efforts in 
increasing computer literacy. 

Contests for individuals and educators 
prompted more than 100,000 entries last 
year during Computer Learning Month. 
Contests this year will focus on effective 
uses of the computer at school and home, 
as well as development of teacher train¬ 
ing materials. Traveling art exhibits fea¬ 
turing creative work done by school-aged 
Children using computers will be dis¬ 
played at metropolitan libraries and air¬ 
ports throughout the country. 

CLF will also promote computer liter¬ 
acy via a nationally syndicated television 
series entitled Softview. The series, pro¬ 


duced in conjunction with the Central 
Education Network, began airing in late 
February and is aimed at increasing ele¬ 
mentary and secondary school educators’ 
understanding and use of computers in 
the classroom. The weekly programs fea¬ 
ture “hands-on” lesson plans incorporat¬ 
ing computer and traditional teaching 
materials, as well as creative computing 
ideas for the classroom. 

This year, sponsorship of foundation 
activities is open to organizations outside 
the computer industry. Through joint 
promotional tie-ins with mass-marketers 
of consumer products, CLF hopes to ex¬ 
tend its “You Won’t Believe What 
You’ll Achieve!” message nationwide. 

Industry sponsorship of Computer 
Learning Month activities in 1988 in¬ 
creased 300 percent over 1987. The 1988 
coalition included 61 software and com¬ 
puter industry members, 52 US state de¬ 
partments of education and Canadian 
ministries of education, and 21 national 
nonprofit organizations. 
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News briefs 


Sutherland receives Turing Award. 

Ivan F.. Sutherland received the 1988 
Turing Award from the Association for 
Computing Machinery February 22 at the 
ACM Computer Science Conference in 
Louisville, Kentucky. The award, which 
includes a certificate and a stipend of 
$25,000, was given to Sutherland for his 
pioneering and visionary contributions to 
computer graphics. 

Sutherland, vice president and techni¬ 
cal director of Sutherland, Sproull, and 
Associates, is the inventor and developer 
of the interactive graphics program 
Sketchpad, which defined the interactive 
computer graphics field 25 years ago. 

NAS honors oustanding achieve¬ 
ment. The National Academy of Sci¬ 
ences will present 11 awards honoring 
outstanding contributions to science 
April 24, during the Academy’s 126th 
annual meeting in Washington, DC. 

Among the 13 recipients of the 11 
awards, John K. Ousterhout, professor of 
electrical engineering and computer sci¬ 
ences at the University of California at 
Berkeley, will receive a $15,000 award 
for initiatives in research, specifically in 
software engineering. This award is 
given in a different field each year to 
recognize innovative young scientists 
and encourage research. 

David Packard, chairman of the board 
of Hewlett-Packard, will receive the 
academy’s Public Welfare Medal in rec¬ 
ognition of “intellectual rectitude, unpar¬ 
alleled generosity, and lifelong dedica¬ 
tion to bettering the quality of America’s 
scientific education and research.” 

Literary award nominations. The 

IEEE-USA is seeking nominations for 
two literary awards. The award for “Dis¬ 
tinguished Literary Contributions Fur¬ 
thering Engineering Professionalism” 
recognizes those who have advanced the 
US professional objectives of the IEEE 
through literary efforts. The award for 
“Distinguished Literary Contributions 
Furthering Public Understanding of the 
Profession” recognizes journalistic or 
other efforts that enhance or expand the 
public’s understanding of engineering. 

Nominations for the first award must 
be made by IEEE members, but the 
award itself is not restricted to members. 
Nominations for the second award can be 
submitted by a US IEEE member or by a 
publisher, author, or radio or television 
station. Forms are available from Wil¬ 
liam R. Anderson, Administrator of Pro¬ 
fessional Activities, IEEE-USA, 1111 
19th St. NW, Suite 608, Washington, 

DC, 20036-3690. 
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“Go East or West 
to move up 
in database.” 


There are two places to move your 
career forward in database systems. 

In the West — with Digital in 
Colorado Springs — we have some of 
the top technical people in database soft¬ 
ware development working on highly- 
sophisticated projects. Nestled in the 
foothill of Pikes Peak, you'll find law 
cost of living, good schools, outstanding 
outdoor recreational activities and 
small-city living. 

In the East — with Digital in Nashua, 
New Hampshire — is our largest soft¬ 
ware development environment — 
where Digital is engineering the prod¬ 
ucts which represent the world’s largest 
installed base of relational database 
products on VAX"'. This is the focal 
point of futuristic database technologies 
that are under development now. Only 
45 minutes from Boston, Nashua repre¬ 
sents the “best of both worlds”... rural 
lifestyle with easy access to big city 
convenience. 


Database Product 
Development 

Colorado/New Hampshire. 

We develop the internals of data¬ 
base products such as Rdb/VMS"', 
Database Distributor and SQL. We 
are also developing the next generation 
of high performance, extended rela¬ 
tional database systems using state-of- 
the-art technologies. We are focusing 
on the design and development of the 
industry’s most advanced and versatile 
database products. 

Database product development 
openings require a BSCS or MSCS 
or equivalent, at least 5 years’ related 
experience, and a strong knowledge 
of database product internals and 
VMS"' or UNIX"'"' internals. Current 
openings include Product Develop¬ 
ment Managers, Principal Software 
Engineers and Project leaders. 

• Database Run Time Systems 
(Colorado/New Hampshire) 

• Distributed Database Products 

(New Hampshire) 

• Multi-Vendor Interoperability 

(New Hampshire) 

• Database Security 
(New Hampshire) 


• Database Languages 
(New Hampshire) 

• Object-Oriented Databases 

(New Hampshire) 

• Database Tools (Colorado and 
New Hampshire) 

• Database Standards 
(New Hampshire) 

Database Performance Analysis 
Colorado/New Hampshire 

Through performance measurement 
and modeling, study existing products 
and designs of future database prod¬ 
ucts to ensure leadership in database 
performance for Digital. Experience in 
performance testing, workload charac¬ 
terization, simulation or analytic 
modeling required. 

Database Architecture 
Colorado/New Hampshire 
Define the architecture and high 
level design for the industry’s most 
advanced and versatile database 
products, which are outlined above. 
Requires depth and breadth of data¬ 
base technical expertise. 

For openings in Nashua, NH: 
Christine J. Baker, Digital 
Equipment Corporation, Dept. 

0301 9133,110 Spit Brook Road, 
Nashua, NH 03062. 

For openings in Colorado Springs, 
CO: Michael Johnston, Digital 
Equipment Corporation, Dept. 

0301 9133,1175 Chapel Hills Drive, 
Colorado Springs, CO 80920. 
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PRODUCT REVIEWS 


Editor: Richard Eckhouse, MOCO, Inc., PO Box A, 91 Surfside Rd., Scituate, MA 02055; Compmail+, r.eckhouse 


Printing the word 


Microcomputer printers have come a 
long way since the high-decibel, low- 
resolution, dot matrix boxes and the 
daisywheel dinosaurs of yesteryear. To¬ 
day, microcomputer owners can choose 
from a bewildering variety of fast, so¬ 
phisticated, 9- and 24-pin dot matrix 
printers at the low end of the price range 
and from a plethora of whisper-quiet la¬ 
ser printers at the high end that rival 
typesetters in print quality. 

This month we feature printers. Be¬ 
cause we couldn’t make our evaluations 
over a large number of printers, we had 
to depend on our reviewers (Dick Eck¬ 
house, Ruth Maulucci, Sorel Reisman, 
and Terry Traub) and what they chose to 
evaluate. Each reviewer, after surveying 
the market, picked a printer model and 
used it in his or her everyday work. At 
the end, each reported back both objec¬ 
tively on the characteristics and subjec¬ 
tively on how well he or she liked the 
printer. Interestingly, each reviewer went 
after a different style of printer and, in 
the end, seemed very pleased with his or 
her choice. 

Canon Bubble Jet 

If you have been using a daisywheel 
(letter quality) printer or are unhappy 
with your dot matrix output because it 
just doesn’t look professional enough, 
you really only have two choices. The 
first, and the one with a lot of pizazz, is a 
relatively expensive laser printer. A sec¬ 
ond choice, and one with equivalent 
quality but at half the price, is an ink jet 
printer. I found the Canon Bubble Jet to 
be one of the industry’s best kept price/ 
performance secrets and recommend that 
you consider it before making a selec- 

The Canon Bubble Jet (BJ-130) is a 
fast and quiet (less than 45 decibels) ink 
jet printer that doesn’t pretend to be a la¬ 
ser printer, as does one of its competi¬ 
tors. After I unpacked it, the easily in¬ 
stalled and used printer was quietly pro¬ 
ducing high-quality output in a few min¬ 
utes. The only assembly required was the 
insertion of two wire suppports and one 
paper-feed knob. Although I don’t rec¬ 
ommend that you ignore the documenta¬ 


tion, I didn’t have to read it to set up the 
printer or to have my word processor 
print a document. 

The Bubble Jet prints 110 characters 
per second in letter quality mode (36 x 
48 dot matrix) and 220 cps in draft mode 
(18 x 36 dot matrix) using a 1 x 48-dot 
bubble jet nozzle. 

The seven-switch control panel on the 
front of the printer allows you to select 
options in Shift or non-Shift modes. Op¬ 
tions include various self-test modes, 
pitch (10, 12, 17, or proportional spac¬ 
ing), draft or letter quality mode, line/ 
form feed, and on/offline switching. You 
can also select white characters printed 
in a black background cell or black char¬ 
acters in a slightly shaded background 
cell. By selecting Expand mode, you can 
print characters one, two, four, or six 
times larger than normal. 

You can select up to four fonts from 
the control panel: the built-in Courier 
font, one or two fonts loaded from font 
packs, and/or a downloaded font. Font 
packs plug into slots located in the front 
of the printer. Gothic, Orator, and Out¬ 
line fonts are available as options. (The 
only other options are a tractor feed, a 
serial interface card that inserts into a 
slot under accessible rear covers, and an 
EPROM for NEC P7 emulation, which 


inserts into the front control panel.) 

Although users sometimes criticize ink 
jet printers for ink smearing, I couldn’t 
make this happen with the Bubble Jet, 
even when I printed a graphics image at 
the full 360 dots-per-inch dot density — 
a density that beats most of the more ex¬ 
pensive low-end laser printers. (Water- 
soluble ink cartridges are rated at one 
million letter-quality characters; the print 
head is rated as having a head life of 100 
million letter-quality characters.) 

If you decide to use “standard” photo¬ 
copy-type paper, you should be aware 
that it has a good side (called the fill 
side) and a bad side (the wire side). 
Printing on the latter side does cause a 
small amount of ink “bleeding.” 

Although it is relatively light (26.5 
pounds), the Bubble Jet’s wide carriage 
is housed within covers that have a large 
footprint (24 x 14.3 x 5.4 inches). If you 
need to print lines of 272 compressed 
characters, the extra-wide footprint is 
worth it. 

The built-in cut paper feed handles 
thin or thick paper (an adjustment lever 
is provided) in 100-page stacks. The 
feeder worked well, with almost no mis¬ 
fed sheets. Because of the way the rollers 
hold the paper, in automatic feed mode 
paper is fed into the printer lower on the 
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page than I would have preferred. By ad¬ 
justing my word processor to print 60 
lines per page, I was able to get even top 
and bottom margins on printed pages. 

Single-sheet feeding is also available 
without having to remove the paper stack 
from the feeder. This mode is useful for 
envelopes. To start printing right at the 
top of the envelope, I had to feed the en¬ 
velope into the printer with the flap open 
— a little unusual, but workable. 

Of course, if you need to address vol¬ 
umes of envelopes or labels, you can use 
the tractor feed. Those who have used 
tractor-fed labels on daisywheel or dot 
matrix printers probably have learned 
never to roll a page of labels backward in 
the platen. I know of nothing more frus¬ 
trating then having to use WD-40 to re¬ 
move labels that become attached to the 
platen. In ink jet printers, this can lead to 
major servicing problems. 

A feature missing from the Bubble Jet 
is a front panel switch combination that 
allows you to dump the buffer once you 
cancel a print job at the computer. Unfor¬ 
tunately, the only way to accompish this 
is by toggling the power off and then on. 

The printer comes with two spiral- 
bound manuals: an English/French/Ger¬ 
man user’s manual and a Control Cap¬ 
sule 48/XL Programmer's Manual. The 
user’s manual is adequate, but you will 
have to experiment to find out how to 
use all the printer’s functions. 

The XL control capsule installed in the 
printer is a removable EPROM chip (the 
control capsule) that makes the printer 
IBM Proprinter XL compatible. The pro¬ 
grammer’s manual contains Basic pro¬ 
grams that use all the printer control 
codes to illustrate how to write new driv¬ 
ers. Although this manual will prove use¬ 
ful to a limited number of users, it is well 
written, illustrated, and organized. This 
manual also describes how to set the two 
10-pin DIP switches to change the prod¬ 
uct’s default settings. 

A number of software companies have 
begun to write software and drivers to 
support some of the unique features of 
the Bubble Jet printer. The Font Factory 
is designing downloadable fonts, 
WordPerfect is developing a driver for 
WordPerfect 5.0, and LaserGo’s Go- 
Script product offers Postscript emula¬ 
tion. 

If you are serious about upgrading to a 
state-of-the-art printer, especially if you 
need to print high-quality graphics, you 
really should consider this $1,095 Canon 
product. I don’t think you will regret 
your decision. You can contact the com¬ 
pany at Canon Inc., One Canon Plaza, 

Lake Success, Long Island, NY 11042, 
phone (800) 892-0020. — S. Reisman 

Reader Service 21 


Diconix Model 150 


I recently bought a laptop computer. 
Although I already own four other com¬ 
puters, I am particularly pleased with my 
newest purchase. I am now a truly port¬ 
able and self-contained person. 

I wanted a laptop long before I actu¬ 
ally bought one. The single reason I de¬ 
layed was because I didn’t know of any 
printer as portable as the computer, and 
the freedom to compute anytime, any¬ 
where, loses a lot of its appeal without 
the freedom to see on paper what I am 
producing. 

Recently, I discovered the Diconix 
Model 150 InkJet Printer. This little 
dandy measures 10.8 x 6.5 x 2 inches and 
weighs in at 3.75 pounds. It’s the perfect 
companion for my laptop. It’s also Epson 
and IBM compatible. 

I am generally impatient with new 
toys. I don’t particularly enjoy exploring 
all the “gee-whiz” features of a new sys¬ 
tem, I just want to figure out as fast as I 
can how to make it do what I need to do 
and get on with it. I must say that I found 
the Diconix easy to get going. The man¬ 
ual is short and sweet, with lots of pic¬ 
tures and tables, and I was able to dem¬ 
onstrate most of the features within min¬ 
utes. 

The printer is amazingly quiet (45 
decibels) and surprisingly fast (up to 240 
characters per second). It accepts single¬ 
sheet or fanfold paper. I found it easy to 
load the paper, and the thing hasn’t 
jammed on me yet. It also has an enve¬ 
lope mode. 

The printer has a number of different 
fonts, such as elite, italic, and script; it 
runs in draft mode (one pass of the print 
head per line) or quality mode (several 
passes over each line); and it can print in 
wide or condensed form. You can set 
some of these options manually with the 
operator panel, while others require es¬ 
cape sequences in program code or pro¬ 
gramming a keystroke. In addition to the 
usual line and form feeds provided, you 
can also back up the paper by doing re¬ 
verse line feeds with the panel. DIP 
switches allow you to change the default 
settings and select the desired interna¬ 
tional character set. The printer supports 
subscripting and superscripting, as well 
as single- and double-density bit image 
mode graphics. 

The printer operates with an AC 
adapter or with batteries, which provide 
a minimum of 50 minutes of continuous 
printing or approximately 150 pages 
without recharging. Five “C” size NiCad 
batteries are encased in, of all places, the 
platen. This is actually quite clever, since 
the platen is exactly the right size to ac¬ 
commodate the batteries, and its insides 


are not used for anything else. What a 
space-saving idea. 

Two things I don’t like about my new 
printer. One is that, unless you use spe¬ 
cial ink jet paper, you get a fair amount 
of bleeding. The other is that, even 
though it is as compact and lightweight 
as anyone could wish, you have to haul 
along a bulky interface cable and a heavy 
adapter/recharger. Maybe when I find the 
right case for all the pieces this nuisance 
will disappear. 

The bottom line is that I have now 
found the ideal match for my new travel¬ 
ing companion, the laptop computer. 

This $499 jewel (often discounted to as 
low as $299) is just what I was waiting 
for, and I will continue to enjoy the new 
freedom it offers. 

For more information about the Dico¬ 
nix product line, contact Personal Printer 
Products, Eastman Kodak, 343 State St., 
Rochester, NY 14650-0406, phone (800) 
255-3434 or (716) 724-5393. 

— R. Maulucci 

Reader Service 22 

Genicom 1040 Matrix 
Printer 

The current trend is towards 24-pin 
dot matrix printers because of their supe¬ 
rior looking output in both text and 
graphics modes. While you can choose 
from many such printers, one that bears 
careful consideration is the 1040, a wide- 
carriage model from Genicom. 

Rated at 360 characters per second in 
10 characters-per-inch draft mode and 90 
cps in near-letter-quality mode, this dot 
matrix printer runs faster than most. It 
offers 10, 12, 15, 17, and 20 cpi as well 
as both proportionally spaced and con¬ 
densed proportionally spaced characters. 

It features Epson LQ2500, IBM Proprin¬ 
ter XL24, and Genicom ANSI emulation 
modes. It is one of the few printers that 
offers three paper-feed mechanisms: 
single sheet plus both rear tractor and 
bottom tractor feed. Options include a 
pull tractor, color printing, and several 
sheet feeders. 

Its obvious ruggedness sets this printer 
apart. This is not a small printer made 
from flimsy parts. Instead, it stands 
higher (6.9 inches) and weighs more (35 
pounds) than most dot matrix printers, 
and it uses a printer/ribbon combination 
that looks built for heavy-duty use. Thus, 
while I didn’t test its longevity, I suspect 
that this printer will last a long time 
without kind treatment. I did find that 
when I caused some interesting paper 
jams that really mucked up the print 
mechanism, all it took to get things run¬ 
ning again was to remove the offending 
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Genicom Model 1040 


bits and pieces of paper. 

I’ve used the Genicom 1040 for sev¬ 
eral weeks now, having substituted it for 
an Epson LQ1050. The substitution is 
entirely transparent, and I have not had 
to change any software (or hardware) as 
a result of the switch. In fact, except for 
a few minor differences, the features and 
functionality of the Genicom are so 
much like the Epson that I hardly notice 
the difference. 

What makes the Genicom different 
from all the other printers I’ve used is 
the full set of “up-front” controls. Except 
for the usual DIP switch settings to select 
a character set, page length, new line se¬ 
quence, compatibility mode, etc., all the 
rest of the choices are made up front. 
From having the on/off switch where I 
want it (up front) to clearing the buffer, 
this printer seems ergonomically de¬ 
signed. Additional front panel choices 
include the usual line feed and form 
feed, cpi choice, font selection, tear-off 
mode, print quality, top margin adjust¬ 
ment, and so on, plus status indicators. 
About the only thing I didn’t care for 
was the membrane panel, which felt okay 
but required several pushes to make it go 
into the on-line condition. 

For those of you unfamiliar with the 
tear-off mode, let me say it’s a feature 
you really should expect in all quality 
printers. It advances the fanfold paper so 
that the perforation stops at the edge of 
the top cover. This allows you to tear off 
the last sheet printed and yet, when print¬ 
ing resumes, to have the paper reset so 
that once again it starts on the top line. 

As a matter of fact, the Genicom 1040 
is the only printer I’ve used that starts 
printing on the top line when you feed in 
cut sheets. I suspect others offer this, but 
it was a constant irritation for me on my 
regular printer, where I could only count 
on 65 lines per page. 

Another up-front feature was the head 
adjustment lever. Since I often change 
from printing a sheet to printing an enve¬ 


lope, I don’t care for a printer where you 
have to open the cover to change this set¬ 
ting. 

Finally, the placement of the font IC 
card in front greatly facilitates using and 
changing the font cards. 

I give this printer high marks in print 
quality. The default Brougham font is 
clear and pleasant. Impressions are dark 
and require a magnifying glass to see 
their dot matrix nature. Draft mode out¬ 
put is fast and more acceptable than what 
several other printers pass off as near let¬ 
ter quality. Rear paper loading is only 
fair, because you really have to work 
from the back to get the paper in cor¬ 
rectly. With other printers, you can often 
reach over the top to perform this feat. 

When it comes to feeding cut sheets 
into this printer, I have mixed reactions. 
A handy paper stop helps you align cut 
forms. It’s marked off in pica characters 
so that you can easily change the left 
margin. But the lack of a right-hand 
guide makes it all too easy to load pages 
in crooked. 

There is nothing unusual about setting 
up this printer. You take it out of the 
box, remove a few shipping pieces, at¬ 
tach a few paper guides, and pop in a rib¬ 
bon. Next you plug in the detachable 
power cord (a useful feature when mov¬ 
ing :he 1040 and one not found in similar 
printers) and attach either an RS-232-C 
serial or Centronics parallel interface 
cable to your computer. The manual 
guides you through these steps pretty 
well. It also describes loading paper, set¬ 
ting the DIP switches, using the front 
panel controls, and interpreting the vari¬ 
ous control codes. However, it is not a 
tutorial on how to take advantage of all 
the capabilities a graphics printer such as 
this has to offer. 

The Genicom 1040 also features a 56- 
Kbyte print buffer that you can split into 
a 24-Kbyte data and a 32-Kbyte down¬ 
load buffer or dedicate entirely to the in¬ 
put data buffer. 


All in all, I like this printer and would 
be happy to use it instead of any other. It 
produces excellent quality results and is 
solidly built, easy to use, fast, and fairly 
quiet. However, at $1,799 it costs more 
than the average for others in its class. I 
would guess that the price difference will 
be more than made up by this printer’s 
speed and reliability over the long haul. 
To find out more, contact Genicom, 
Genicom Dr., Waynesboro, VA 22980, 
phone (703) 949-1170. — R. Eckhouse 

Reader Service 23 

Hewlett-Packard 
DeskJet Professional 

Until recently, those seeking true let¬ 
ter-quality output had no alternative but 
to spend upwards of $2,000 on a hefty 
office laser printer. Hewlett-Packard of¬ 
fers a new option with the introduction 
of its latest ink jet printer, the Hewlett- 
Packard DeskJet Professional Printer. 
Like laser printers, the DeskJet claims 
quiet operation, clear black text in mul¬ 
tiple typefaces, and 300 dots-per-inch 
graphics output, but its list price of $995 
(often discounted to as low as $700) is 
closer to that of high-end dot matrix im¬ 
pact printers. 

The Hewlett-Packard DeskJet Profes¬ 
sional Printer prints on any plain paper, 
but printouts look best on heavier rag 
content paper. The claimed print speed is 
120 characters per second in letter qual¬ 
ity mode and 240 cps in draft quality 
mode; both speeds are for 10 pitch (10 
characters per inch) Courier, the native 
typeface. The printer can also print 5, 
16.67, and 20 pitch Courier. 

Two cartridge slots support additional 
typefaces and memory. Cartridges cost 
extra, but the review printer came with 
Times-Roman and Helvetica cartridges 
in addition to the built-in Courier type¬ 
face. Other cartridges, not tested for this 
review, include 128-Kbyte RAM expan¬ 
sion for downloading soft fonts, Epson 
FX-80 printer emulation, and Prestige 
Elite. The printer is not really complete 
without at least the Times-Roman car¬ 
tridge, which would add about $100 to 
the price (depending on the dealer). 

The printer comes with both parallel 
and serial ports. 

I found it easy to set up the DeskJet; 
all I had to do was plug in a parallel 
cable between the printer and the com¬ 
puter (a 20 MHz, 80386-based AT) and 
set a switch on the back of the printer for 
parallel. The paper tray and cover slid 
into place, the cartridges went into the 
two cartridge slots, and I turned the 
printer on. No other physical installation 
was required. Instructions in the manual 
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clearly explained installation with pic¬ 
tures and text. The manual also included 
specific installation instructions for cer¬ 
tain computers. With the printer came 
two diskettes with printer drivers for 
various programs. Batch files explained 
how to copy the drivers onto the appro¬ 
priate system. 

I tested the DeskJet with Microsoft 
Excel, Windows Write (the word proces¬ 
sor that comes with Microsoft Win¬ 
dows), Harvard Graphics, Fontasy, and 
Microsoft Word 4.0. I encountered no 
difficulties using this software. Word 
produced a slightly jagged but acceptable 
output with the Times-Roman typeface, 
and Harvard Graphics produced charts 
that resembled LaserJet output. 

The DeskJet, although not as fast as 
HP’s LaserJet laser printer, was plenty 
fast enough in letter quality mode for 
short documents, and I thought it as quiet 
as a LaserJet. Graphics, such as those 
produced with Harvard Graphics and Ex¬ 
cel, took a long time to print, but the re¬ 
sults were excellent and looked nearly as 
good as LaserJet output. The DeskJet’s 
graphics commands are supposedly the 
same as the LaserJet’s; certainly I was 
able to make correct graphical printouts 
using Fontasy installed for a LaserJet 
Plus. Other DeskJet printer codes deviate 
slightly from the LaserJet standard, but 
for the most part I found it easy to print 
things from within programs and from 
the DOS prompt. 

The manual that comes with the 
printer fully documents the paper han¬ 
dling codes and the graphics commands 


and includes a rudimentary program to 
illustrate graphics programming. Anyone 
who has used LaserJet printer codes will 
feel at home with the DeskJet language. 

Many features of the DeskJet printer 
are reminiscent of the LaserJet printer. 
The ink cartridge and ink-jet head are 
contained in a single, disposable unit. As 
with the LaserJet, control buttons on the 
front let you reset the printer, eject pa¬ 
per, choose typefaces and sizes, and run 
the self-test procedures. I found the con¬ 
trols simple to operate compared to the 
controls on the LaserJet. 

The paper tray holds 100 sheets of cut 
sheet letter or legal size paper — slightly 
skimpy when compared to laser printers, 
which hold 200 or more sheets. The 
DeskJet has no tractor feed mechanism, 
so you must remain near the printer to 
replenish the paper when you have a long 
printout. Unlike pin feed printers, how¬ 
ever, you can use any color or variety of 
paper in the DeskJet. 

The DeskJet knows how to print enve¬ 
lopes, but it takes a little persuasion 
sometimes. It can accept envelopes up to 
9.5 inches in width. After carefully feed¬ 
ing in an envelope (you do not need to 
remove the paper), you must press two 
buttons on the printer’s control panel to 
load it. I found it difficult to feed in the 
envelope; often, the right corner of the 
envelope would get bent in the mecha¬ 
nism and the printer would jam. Bending 
up the right comer of the envelope a 
little helped prevent jamming. Printing a 
stiff envelope is out of the question be¬ 
cause of the sharp turn it must make. 


The envelope feature needs some im¬ 
provement to be practical for office use, 
but it is acceptable for the occasional let¬ 
ter, once you have learned how to use it. 
The user who masters this skill will be 
rewarded with envelopes that look type- 

The quality of the DeskJet’s printing 
was uniformly excellent and stood up 
against that of most laser printers. In 
fact, I found it difficult to tell the differ¬ 
ence. One problem, however, is that the 
ink tended to blot somewhat on cheaper 
paper. The blotting appeared on standard 
20-pound photocopier paper, but not on 
high-quality 24-pound 100-percent cot¬ 
ton fiber paper. Indeed, the manual rec¬ 
ommends using heavier paper, but for 
anything short of presentation quality 
printing, the lighter paper yields toler¬ 
able results. 

The only other problem I encountered 
was that the ink did not dry immediately; 
the ink on a fresh printout smeared eas¬ 
ily. Only after several hours did the ink 
become completely dry and indelible. 
Hewlett-Packard’s technical support told 
me they were testing a new ink formula 
that will be less prone to blotting and 
smearing, but it was not available for 
testing during this review. 

According to HP, an ink cartridge lasts 
for 500 pages of typical business letters 
(40 percent use of page) at letter quality 
or 1,000 pages at draft quality. Graphics 
printouts would use ink more quickly. 

The DeskJet was not designed to print 
large volumes of material, but it is ap¬ 
propriate for the home user or small 
business. 

I consider the DeskJet a fine printer, 
well designed and capable of replacing a 
laser printer for most purposes. If you 
can afford a laser printer, you should cer¬ 
tainly get one. If not, the DeskJet offers a 
fine compromise between price and print 
quality. Contact the Peripherals Group, 
Hewlett-Packard, 16399 W. Bernado Dr., 
San Diego, CA 92717-1889, phone (619) 
592-8068. — T. Traub 
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Kyocera F-1000A 
Laser Printer 

Shopping for a laser printer is not an 
easy task. There are many models to 
choose from, with greatly varying capa¬ 
bilities, and priced from something over 
$1,000 to well over $10,000. In my case, 
choosing a laser printer to review meant 
finding something in the $2,500 price 
class that offered as many features as 
possible with a low cost of ownership. 
What attracted me to the Kyocera F- 
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Kyocera F-1000A 


1000A was its 79 resident plus three dy¬ 
namic fonts, 1.5 Mbytes of memory, HP 
LaserJet Series II compatibility, and eas¬ 
ily replaced toner and drum. 

Kyocera, a relatively new entrant in 
the laser printer field, offers its own laser 
engine. The machine is not as compact as 
others, measuring 16.9 x 17.7 X 12.6 
inches and weighing in at 57 pounds. But 
it’s a solid performer, turning out 10 
pages per minute after a warm-up period 
of just 22 seconds. The print quality is 
excellent, ranging from a very dark black 
to an impressive looking 300 x 300 dots- 
per-inch graphic image. An interesting 
feature is the 39 barcode types built in, 
including UPC, Code 39, Codabar, and 
EAN. Another valuable feature is the 
seven printer emulations: Diablo 630, 
Qume Sprint II, NEC Spinwriter, IBM 
graphics printer, HP LaserJet, Epson FX- 
80, and line printer. 

The paper cartridge holds 250 sheets. 
The paper path is straight through and 
looped back so printed results stack up in 
proper order on top of the printer. A 
manual feed guide on the paper tray 
makes it a snap to substitute a different 
paper size or feed in an envelope. Should 
you need to get inside the machine, the 
clamshell design makes it easy to pop the 
unit open to correct a misfeed or change 
the drum. 

Unlike other laser printers, the F- 
1000A design does not allow you to in¬ 
crease memory beyond the 1.5-Mbyte 
limit. While this amount of memory is 
sufficient for most applications, it will 
not be enough for some heavy graphics 
work. 


You can add nonresident fonts using 
special IC cards (priced from $150 to 
$205) that slide into the front of the ma¬ 
chine. Kyocera can customize these 
cards to hold signatures and logos that 
you specify. Alternatively, you can buy 
an IC Card Launch Kit that includes a 
PROM burner and five IC cards. 

Enough statistics — what does this la¬ 
ser printer really offer? For me, the an¬ 
swer is, everything I could want! The F- 
1000A is a fully loaded laser printer 
without an inflated price. When I consid¬ 
ered other alternatives, I found that, in 
addition to the purchase price, I would 
have to shell out nearly an equal amount 
for font cartridges and additional mem¬ 
ory just to make the other printers 
equivalent to the F-1000A. Thus, even if 
I bought this machine at the full list price 
of $2,895, it would still cost less than 
other machines I could buy at discount 
but with only a handful of fonts and 0.5 
Mbytes of memory. 

Printer emulation was also a factor for 
me, since much of my work has de¬ 
pended on either an IBM or Epson 
printer with extended graphics or italic 
characters. Switching from one emula¬ 
tion mode to another isn’t at all difficult 
on the F-1000A, although it’s greatly fa¬ 
cilitated using a utility such as Laser- 
Menu (see the accompanying review). As 
a result, I found this one printer replac¬ 
ing several others currently in use. 

Even before LaserMenu, I had pro¬ 
grammed the F-1000A using the built-in 
Prescribe command language. Again, un¬ 
like other laser printers that depend on 
escape sequences to set the desired char¬ 


acteristics, Kyocera has provided an eas¬ 
ily remembered set of commands for 
page control, orientation, spacing, cursor 
position, and font selection, as well as 
for obtaining device status, generating 
vector and raster graphics, and generat¬ 
ing bar codes. 

The Prescribe commands are ASCII 
strings that you can embed in any pro- 
. gramming language to make the F- 
1000A perform rather sophisticated op¬ 
erations. What makes using these com¬ 
mands, and operating the laser printer, so 
easy is the excellent manual set. You get 
a user’s manual, a programming manual, 
and a quick reference guide, each on a 
par with the high quality manuals that 
HP and Epson users are accustomed to. 
Each is thoroughly indexed and, in the 
case of the programming manual, in¬ 
cludes lots of examples. A chapter on 
emulation modes thoroughly explains the 
features of each. Having tested the F- 
1000A in IBM, Epson, and HP modes, I 
found the emulations to be complete and 
exact enough that all the utilities written 
for each worked on the F-1000A without 
a problem. 

The Kyocera laser printer family in¬ 
cludes not only the F-1000A but also the 
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An alternative for printer supplies 


wnne you can buy your computer 
supplies directly from either the equip¬ 
ment manufacturer or the selling 
dealer, it’s often more economical to 
go to a second source. In the case of 
laser toner cartridges, Pelikan, a well 
known supplier of printer ribbons, has 
added the Kyocera brand to its line. 
The company already offers supplies 
for both the Cannon and Ricoh en¬ 
gines. And, while you can't purchase 
directly from Pelikan, you can go to 
places like Moore Computer Supplies 


and other national direct-mail supply 
houses. 

Pelikan provides a toner replacement 
kit for the Kyocera that is nearly identi¬ 
cal to the original equipment that 
comes with the F-1000A. |n-use tests 
have been consistent with the original. 
That isn’t a surprise, since Pelikan 
guarantees its products to meet or ex¬ 
ceed the manufacturer’s specifications. 

Contact Lynn Redmond at Pelikan, 
200 Beasley Dr., Franklin, TN 37064, 
phone (615) 794-9000, ext. 218. 


F-2010 and F-3010. These machines in¬ 
clude features like dual paper cassettes, 
larger console selection panel, face-up 
and face-down output, sheet feeders, col¬ 
lators, and faster printing speed. But, for 
my money, the F-1000A has all I need. I 
have used this printer for several months 
now and rate it outstanding. I have found 
nothing else in its price range that is 
comparable. 

During my testing and evaluation, I’ve 
made over 4,000 copies with the F- 
1000A. Along the way, I have had to re¬ 
fill the toner and replace the drum. When 
I had printed about 3,500 pages, the 
toner light came on. It took less than a 
minute to open a cover in the top of the 
unit, pull out the old cartridge, and drop 
in a new one. A second step replaces the 
toner overflow bottle and the fuser clean¬ 
ing pad. The complete refill kit set me 
back only $27 and will be good for an¬ 
other 3,000-plus copies. 

My machine had already made 6,000 
copies (indicated by the counter) when I 
got it. The drum has a separate, built-in 
counter that signals the indicator panel 
when it passes the 10,000th copy. When 
the indicator panel signalled the need to 
change the drum after the additional 
4,000 copies, I didn’t really see the need 
because the print quality was still excel¬ 
lent. But I decided to do so anyway, and 
in less than two minutes I had removed 
the old drum and replaced it with a new 
$170 unit. No fuss and no mess. A call to 
tech support confirmed my guess that the 
warning comes as a lower limit, so it’s 
up to you to decide when print quality is 
unacceptable and a new drum needs to be 
installed. 

I’ve noticed that I can’t find many ads 
in computer magazines for Kyocera. 
Given that these are high quality ma¬ 
chines with loads of built-in features that 
don’t cost extra, they represent a real 
value. I hope that some of the mail-order 
houses will discover this hidden gem and 
start offering it. Given how well the ma¬ 


chine is packed for shipping, mail-order 
shouldn’t be any more of a problem than 
it is for a computer system. 

Several OEMs have discovered this la¬ 
ser printer and are now reselling the 
printer under their own label. Thus, you 
will find lots of dealers selling not only 
Kyocera but rebranded machines, mak¬ 
ing availability good to excellent in 
terms of both the unit itself and supplies 
(for one source of supplies see sidebar). 

As you can tell, I really love this 
printer. It works and works, never jams, 
and prints better than any other machine 
I’ve used or seen. All the software I nor¬ 
mally use works perfectly with the F- 
1000A, either in HP emulation mode or 
directly under Microsoft Windows, 
which includes a Kyocera driver, so I can 
use all of the F-lOOO’s built-in features. 
At this point, I can’t imagine working 
without it. 

You can get more information from 
Kyocera Unison, 3165 Adeline St., 
Berkeley, CA 94703, phone (415) 848- 
6680. — R. Eckhouse 
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LaserMenu, a laser 
utility 

Many years ago, I reviewed an out¬ 
standing product called PrintMenu. This 
utility from MicroLogic Software was an 
easily used RAM-resident program that 
provided complete control for my dot 
matrix printers. It’s so handy that I con¬ 
tinue to use the program today. 

When I saw that MicroLogic offered 
LaserMenu, I knew I had to try it out. 
While dot matrix printers have many fea¬ 
tures that can benefit from a printer con¬ 
trol utility, laser printers demand such a 
utility because they have so many more 
features to contend with that you can 
only begin to tap their potential with 
most application programs. LaserMenu is 


“the” utility to have. It expands the range 
of applications that really take advantage 
of owning a laser printer and makes it 
possible to generate results from soft¬ 
ware that doesn’t even support a laser 
printer. Frankly, I would be lost without 
the support that LaserMenu offers for all 
my daily printing tasks. 

What can you do with LaserMenu? 
First, you can change the default combi¬ 
nation of features available on your laser 
printer so that all subsequent text output 
will reflect these features. In fact, you 
can enable output filtering so that subse¬ 
quent escape codes don’t reset the 
printer. Also, you can store these 
changes as user profiles to be recalled 
whenever you wish to change the current 
settings. 

Second, you can insert LaserMenu 
macros in your text file to provide under¬ 
lining and font changes at selected 
points. These same macros form the ba¬ 
sis for the forms generation tool, which 
allows you to produce professional look¬ 
ing forms. To get you started, Micro- 
Logic includes a sample telephone mes¬ 
sage demo form that illustrates using 
emphasized text with multiple boxes, 
lines, and shading. 

Third, LaserMenu includes download¬ 
ing of softfonts and selection of cartridge 
fonts. As a RAM-resident program, La¬ 
serMenu doesn’t require you to leave 
your current application to do this. 

Fourth, complete printer redirection is 
included, so you can force output to a la¬ 
ser printer connected to either a serial or 
parallel port. Another option lets you 
“transform” your laser printer into a 
compatible dot matrix printer. 

Fifth, the software comes with con¬ 
text-sensitive help built in, called up by 
the FI key at any time and within any 
menu. Thus, even though you get a 
user’s guide for this software, you really 
won’t need it unless you want more de¬ 
tailed information. 

For $99.95, LaserMenu is a utility you 
can’t afford not to have. Its pulldown 
menu style, low system overhead (less 
than 66 Kbytes), and wide range of sup¬ 
port for systems (any IBM PC, XT, AT, 
PS/2, or compatible), mice (Microsoft 
Mouse and compatibles), and printers 
(HP and compatibles, ALPS, AST, Citi¬ 
zen, C.Itoh, Epson, Kyocera, Okidata, 
Panasonic, Mannesmann Tally, NEC, 
QMS, Sharp, Star Micronics, Toshiba, 
and Xerox) make it a utility that will 
quickly pay for itself in simple conven- 

Contact MicroLogic Software, 6400 
Hollis St., Suite 9, Emeryville, CA 
94608, phone (800) 888-9078 or (415) 
652-5464. — R. Eckhouse 
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Financial modeling — the solution to 
spreadsheet problems 

Sorel Reisman, University of California at Fullerton 


Large corporations have long practiced 
strategic planning using mainframe- 
based decision support systems (DSS). 
Smaller companies that have more re¬ 
cently begun using microcomputers to 
manage their day-to-day businesses are 
beginning to understand the importance 
of strategic planning, even in small en¬ 
terprises. Unfortunately, the best strate¬ 
gic planning tools available for micro¬ 
computers have mainly been spread¬ 
sheets, a product type not really well 
suited for strategic planning. 

Software vendors who have ported 
their mainframe DSS products to micro¬ 
computers have discovered a reluctance 
on the part of microcomputer users to 
capitalize on the features and benefits of 
DSS. Some of the inadequacies of early 
versions of the DSS micro products justi¬ 
fied this reluctance. However, today, mi¬ 
crocomputer users who fail to use DSS 
products jeopardize their businesses by 
continuing to use the wrong tools for 
strategic planning. 

MicroSimplan is a microcomputer- 
based decision support system that can 
serve as an excellent example of the cor¬ 
rect tool to use for business planning ap¬ 
plications. MicroSimplan is the micro¬ 
computer version of the mainframe prod¬ 
uct Simplan. 

MicroSimplan, which comes on mul¬ 
tiple diskettes together with two manu¬ 
als, runs under MS- or PC-DOS, version 
2.0 or later, and requires either a hard 
disk drive (recommended) or two floppy 
disk drives. All system modules require 
at least a monochrome monitor except 
for the Graphics Module, which supports 
CGA, EGA, or VGA. 

Although the product requires a mini¬ 
mum of 384 Kbytes of memory, it fea¬ 
tures a virtual paging architecture that 
automatically moves pages of “Work¬ 
space” (memory) to and from disk in a 
work session. You might expect a notice¬ 
able performance degradation when pag¬ 
ing takes place, but the nature of micro- 
based financial modeling is such that 
work sessions are computation bound 
rather than I/O bound. (MicroSimplan 
does support 8087/80287 math coproces- 

One of the product’s notable deficien¬ 
cies is that the only hardcopy device it 
directly supports is a plain Epson printer. 
To use the special features of other 
hardcopy devices requires generation of 


the control characters (set-up strings) 
needed, for example, for a color printer 
or a plotter. You can do this either in a 
Report Generator procedure or by using 
an editor to insert the strings into a re¬ 
port written to disk prior to generating 
hardcopy. Future releases of the product 
will reportedly support other output 
devices. 

Micro versus mainframe 
versions 

The price differences between the mi¬ 
cro and mainframe versions of the prod¬ 
uct reflect some of the philosophical dif¬ 
ferences between the two market seg¬ 
ments. MicroSimplan, together with a 
graphics and communications compo¬ 
nent, costs $895. Users who wish to de¬ 
velop runtime applications can purchase 
the Application Manager for an addi¬ 
tional $595. A runtime version costs 
$295 per application. 

Mainframe Simplan costs $60,000, 
with four additional mainframe-related 
modules available at $5,000 each. The 
mainframe-resident portion of the Com¬ 
munications Module, required for seam¬ 
less communication between MicroSim¬ 
plan and mainframe Simplan, costs 
$3,000. Lease and maintenance plans are 
available for the mainframe product, and 
site licenses are available for both. 

The large difference in price between 
the products invites questions regarding 
the features of the two. For the most part, 
the products have equivalent features ex¬ 
cept that MicroSimplan does not support 
some of the more esoteric statistical 
functions that exist in the mainframe 
version. 

Data security. Unlike the mainframe 
product, which can provide restricted ac¬ 
cess to data (down to the record level) as 
well as to user-developed application 
procedures, MicroSimplan provides pass¬ 
word security only at the database level. 
This can be an important factor in decid¬ 
ing whether or not to adopt the micro or 
mainframe version for corporate use. 

User interface 

Session log screen. When you load 
the system, it displays the session log 


screen. The first and 25th lines contain 
status information regarding the active 
disk directory and the current time. Line 
24 is the command line into which you 
enter MicroSimplan commands. This line 
is similar to the spreadsheet command 
line. 

You can execute a command immedi¬ 
ately by entering it into the command 
line and pressing the Enter key, or you 
can store it as part of executable pro¬ 
grammed procedures. You can edit en¬ 
tries in the command line using conven¬ 
tional spreadsheet-like edit features. 
When a command is executed, the text in 
the command line scrolls into the log 
screen. As more commands are executed, 
they move into the log screen, causing 
previously logged commands to scroll 
upward. A user-selectable buffer of 20 
to 10,000 lines can be logged in this 
fashion. 

It is possible to move the cursor into 
the log screen. Using arrow or page con¬ 
trol keys, you can move the cursor to an 
old command and move that command 
into the command line for editing and 
execution as a new command. 

Help. Context-sensitive help screens 
interconnected in a tree-like fashion are 
available by pressing the FI key. Higher 
level screens display highlighted key¬ 
words that you can use for hypertext-like 
branching to other help screens. 

Key assignment. Simplan Systems, or 
SSI, maintained a mainframe-like key¬ 
board definition for the micro product. 

So, for example, the use of F4 to escape 
from a function seems a little strange. To 
SSI’s credit, however, default function 
key assignments are consistent among all 
the modules, so users who learn the de¬ 
fault key definitions will not be at any 
disadvantage. 

MicroSimplan does not directly sup¬ 
port a mouse and, in its current version, 
probably does not require one. 

Additional comments on the user 
interface. For the most part, MicroSim¬ 
plan is a command-driven system. This is 
not surprising, considering its IBM 3270 
heritage. A consequence of the implem¬ 
entation of the product on microcompu¬ 
ters is a schizophrenic user interface that 
sometimes displays colorful windows 
with user-selectable options and some- 
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times leaves you facing a blank com¬ 
mand line, wondering what to do next. 
Subsequent versions of the product will 
probably include a more complete win¬ 
dows interface. The Screen Manager 
module makes the development of 
windows a relatively straightforward 
process. 

Program structure 

MicroSimplan, like its mainframe 
counterpart, consists of six integrated 
functional modules. Two of these that 
are completely self-contained are the 
full-screen editor (similar to the IBM 
Personal Editor) and the communications 
module. 

The four other functional modules are 
modeling, business graphics, reporting, 
and screen management. These modules 
are definable in terms of a MicroSimplan 
programming language with subsets of 
commands particular to each module. 

The product also has a syntax and com¬ 
mand-set common to the entire system. 
With the editor, you can write proce¬ 
dures to produce a report, display busi¬ 
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ness graphics, generate pull-down 
menus, and execute complex financial 
simulations. 

In addition to these functional mod¬ 
ules, MicroSimplan also contains an Ap¬ 
plication Manager that allows you to 
compile and execute models, reports, 
screens, and graphs as runtime modules. 
Used in this fashion, the runtime mod¬ 
ules do not require the full product to 
execute. 

The ability to run the full version of 
Simplan on a micro arises from its modu¬ 
lar architecture. Normally, the product is 
used on a module-by-module basis, with 
some modules never required by some 
users. Typically, you would use the prod¬ 
uct interactively or with the editor oper¬ 
ating with one module for an extended 
period of time. The software imposes no 
such restriction. 


Database perspective 

Financial modeling focuses on data in 
a database. MicroSimplan is designed 
around a three-dimensional data structure 
that defines the dimensions of such a da¬ 
tabase. The data structure is usually first 
defined as a single file (File 1) in two 
dimensions. 

After the structure of File 1 is defined, 
additional planes or files are usually de¬ 
fined with the same structure. In a typi¬ 
cal application, File 1 might represent 
the structure of the quarterly budget of 
one division within a company; File 2, 
the quarterly budget of another division, 
etc. There are no limits to the number of 
records, time periods, or files comprising 
the definition of a data structure. 

The database does not require any 
physical disk storage unless a file, pe¬ 
riod, or record is actually used. For ex¬ 
ample, if different divisions produce or 
sell different products and these products 
are stored in the records dimension, Mi¬ 
croSimplan does not store information on 
all the products (records) for all the divi¬ 
sions (files) unless they pertain to the 
particular division. 

Viewing the database structure. 

Once a database structure has been de¬ 
fined, you can examine it from any two- 
dimensional perspective using the View 
instruction. When a View command is 
executed, function keys facilitate view¬ 
ing of the database. Example functions 
are (a) display the next layer, (b) display 
the previous layer, (c) rotate to a differ¬ 
ent dimension of the database, and (d) 
switch rows and columns of the display. 

The View command is extremely pow 
erful and unlike any function found in 
spreadsheet products that allow for a 


third dimension of data. Because the 
View command will display data in any 
order in any dimension, you can use it to 
provide a preliminary view of output re¬ 
ports generated by the Report Generator. 


Database creation. After the database 
structure is defined, data can be entered 
as a result of calculations from a proce¬ 
dure in the Modeling module, loaded 
from disk, imported from another micro 
application, or downloaded from another 
computer. When you use these methods, 
data elements are assigned to particular 
record names, file names, and periods. 

You can also enter data from the key¬ 
board in a fashion similar to the method 
used with a spreadsheet. The format of 
data saved in the database, unlike spread¬ 
sheet products, is completely independ¬ 
ent of the format of output reports. 

Global commands specify the number 
of decimals displayed, but 16 significant 
digits are carried by the system. Another 
global command defines field widths. 
Data, which can only be numeric, are al¬ 
ways right justified with the decimal 
points lined up. Negative numbers are 
indicated with minus signs. When too 
many digits are entered for the global 
definition, all the decimals are stored but 
the displayed number is rounded. Num¬ 
bers too big for a field are converted to 
exponential. 

With a block-marking function, values 
can be propagated or replicated through a 
row, column, or block. You can create 
new cell values or calculate them from 
existing ones. You can also create new 
records during this process. When you 
create new records, they are automati¬ 
cally propagated through the three-di¬ 
mensional space. You can save these 
changes to become a part of the database 
structure definition. 

You can also import data in ASCII for¬ 
mat from other applications. You can 
direct such data anywhere in the three- 
dimensional database using the Load 
command and appending the list of desti¬ 
nation records in the data file. Another 
method is to load the ASCII data file into 
the MicroSimplan editor, insert a record 
destination list at the top of the data file, 
and, with the Import command, use that 
list as if it were entered in the command 
line. 

You can also copy existing data from 
one database to another. When copying, 
downloading, or importing, data records 
that do not already exist in the database 
structure can be specified as targets, and 
the system will create those records be¬ 
fore transferring new data values. In Mi¬ 
croSimplan, you can assign passwords to 
databases to provide a lockout feature for 
unauthorized users. 
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The micro-mainframe 
link 

MicroSimplan contains a micro-main¬ 
frame link to upload/download files be¬ 
tween the micro and a mainframe. The 
link supports asynchronous communica¬ 
tions as well as popular 3270 emulation 
boards. 

To use this facility, you must invoke 
the micro-resident communications mod¬ 
ule included with MicroSimplan. The 
mainframe can be attached via a regular 
asynchronous or synchronous path with 
mainframe Simplan running or, alterna¬ 
tively, with only SSI’s Advanced Com¬ 
munications Component (a $3,000 op¬ 
tion) loaded. 

If the mainframe communication op¬ 
tion is loaded, the micro module can di¬ 
rectly access mainframe Simplan files 
and download them to the active Work¬ 
space. Alternatively, files can be 
uploaded for mainframe Simplan’s later 
use. The two SSI communications mod¬ 
ules together convert file formats and, 
with built-in compression/expansion and 
error checking algorithms, speed up data 
transmission by as much as 10 times, de¬ 
pending on the nature of data being 
transmitted. 


Consolidation 

One of the most important features of 
three-dimensional modeling products is 
their ability to consolidate data in a data¬ 
base. This simply means having the abil¬ 
ity to add meaningful entities across mul¬ 
tiple dimensions. 

For example, suppose the files in a Mi¬ 
croSimplan data structure represented the 
quarterly sales by product of each branch 
in a company. If the vice president of 
sales wanted to obtain a view of the total 
company sales for each product, he or 
she could use the Add command to pro¬ 
duce a new file consolidating all the 
files. Usually you could do such a simple 
consolidation with some of the new 
spreadsheet products, but only if each of 
the spreadsheet planes is identical in 
structure. Also, consolidation with 
spreadsheets can usually only be done 
across equivalent records in each of the 
planes. And, when you do that kind of 
limited consolidation, the result is an¬ 
other two-dimensional spreadsheet inter¬ 
woven with intercell logical relation¬ 
ships. 

MicroSimplan’s Add command allows 
for consolidation of any variables across 
any dimensions. With the View com¬ 
mand you can examine the result from 
any perspective. Unlike the spreadsheet, 
the resultant MicroSimplan file is com¬ 


posed of data values that are independent 
of any other program logic. 

Modeling 

As mentioned above, MicroSimplan 
executes commands from the command 
line or from within procedures prepared 
in the editor and executed by the appro¬ 
priate module. You write models using a 
structured programming-like syntax with 
assignment statements, conditional (if/ 
then/else) and unconditional (goto .. to 
alphanumeric labels) transfer of control 
statements, and looping (while/end). As¬ 
signment statements use conventional 
arithmetic operators in algebraic format. 
The use of parentheses provides tradi¬ 
tional precedence of operation. 

The product has an extensive library 
of arithmetic, trigonometric, statistical, 
and financial functions, and models can 
be called as functions from other models. 

Execution of models. One of Micro¬ 
Simplan’s system commands that causes 
a pop-up menu to appear on the screen is 
the Status command. The options that 
you can set in this menu allow you to 
specify the list or range of records, peri¬ 
ods, and files that will be displayed when 
a model is executed. (Status also speci¬ 
fies the same information for many other 
commands.) 

You can use the Status command to 
set the periods and files for which the 
model logic will be solved. The order of 
execution of a model is to apply each se¬ 
quential statement in a procedure to all 
the columnar data within a period in the 
data file, reexecute the procedure for all 
the data in the next period, and so on un¬ 
til the first file has been completely pro¬ 
cessed. The pattern repeats until all the 
files selected have been processed se¬ 
quentially. You can control this implicit 
order of execution by resetting the status 
before executing the model. 

You can set up models to directly pro¬ 
vide simultaneous solutions for two or 
more interdependent variables. Prior to 
issuing the Model Solve command, you 
can set the number of iterations and the 
convergence level to be used by the 
Gauss-Seidel algorithms MicroSimplan 
employs for this process. 

You can use the modeling process to 
answer what-if questions in a manner 
similar to that used with spreadsheets. 
You can change data values in the data¬ 
base and run the model to see the effect 
of the change. 

A more elegant method, and one that 
allows you to experiment with alterna¬ 
tive data relationships, is to simply mod¬ 
ify (edit) a formula in a model and rerun 
it against a database. If you tried such an 
experiment with a spreadsheet, you 
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would need to edit every cell in the 
spreadsheet in which the formula re¬ 
quired modification. With the modeling 
system, one formula change is relevant 
to all data across all three dimensions. 

Goal seeking 

Another important feature of modeling 
systems, goal seeking, allows the analyst 
to set the values of records in a database 
and direct the system to backtrack 
through all dependent records to calcu¬ 
late the values of those records that 
would actually produce the goal values 
set. In MicroSimplan, you merely issue 
the Goal command to invoke a pop-up 
menu that solicits the information neces¬ 
sary to execute goal seeking. 

Report Writer and 
Graphics 

The Report Writer and Graphics mod¬ 
ules contain a complete syntax of com¬ 
mands to produce reports in virtually any 
format, as well as a variety of graphics. 

The Report Writer contains arithmetic 
and growth rate library functions that can 
operate on existing database values and 
create new columns and/or rows in a 
generated report. Reports can extend up 
to 256 columns wide. You can print them 
immediately, save them to disk for word 
processing, or write them to the Work¬ 
space for previewing. Horizontal screen 
scrolling lets you preview reports wider 
than 80 characters in the Workspace. 


Review notes 

New Tango PCB software. The new 
Tango Series II circuit design packages 
are out and they are really worth looking 
at. In an earlier review I praised the first 
series for advancing the state of the art 
for PC-based machines. The new ver¬ 
sions of printed-circuit-board layout and 
routing software now feature pop-up 
menus and dialog boxes to replace the 
previous hard-to-remember command 
structure. Additionally, they have user- 
definable macros, on-screen prompts, 
context-sensitive help, and screen hot 
spots that increase user productivity. The 
software takes advantage of my Paradise 
VGA Professional card (and others as 
well) to provide an impressive 800 x 600 
resolution display. Support for a large 
number of display cards, printers, and 
plotters, plus normal, reverse, prototype. 


MicroSimplan’s report writing process 
is far more flexible than that provided in 
spreadsheet products because of the inde¬ 
pendence of the database from the actual 
format of the output report. One of the 
biggest problems with spreadsheets arises 
when you need to produce a report whose 
rows or columns differ from the actual 
spreadsheet. The editing needed to ac¬ 
complish this can be completely avoided 
with MicroSimplan. 

The Graphics module provides bar, 
line, pie, scattergram, and word chart rep¬ 
resentations of data. There are options to 
select graph type, data to plot, colors, 
scaling, graph positioning, stacking, etc. 
Graphic images can be saved as .pic files. 


Application Manager 

The Application Manager is an optional 
module that stores a series of MicroSim¬ 
plan commands into procedures and al¬ 
lows them to be executed with a Micro¬ 
Simplan runtime module. The Application 
Manager has two parts, the Screen Man¬ 
ager and the Application Development 
component. 

The Screen Manager lets you create 
and display windows containing menus 
and forms. You can prepare a Screen 
Manager file with the editor using screen 
function commands that draw menus and 
forms with different colors and borders 
anywhere on the screen. You can design 
menus to contain selectable options that, 
when invoked, can display other menus, 
execute models, display data entry forms, 
print reports, etc. 


and Gerber output makes this software 
valuable for the novice as well as the 
professional. The PCB package lists for 
$595 and the router is $495, both with a 
30-day money-back guarantee and one 
year of free updates. Combined into 
CADPak, they cost $995. A no-charge 
evaluation package can be had by calling 
(800) 433-7801. Accel Technologies, 
7358 Trade St., San Diego, CA 92121, 
phone (619) 695-2000. — R. Eckhouse 

New manual for PC Genius Newton. 

Those who purchased a PC Genius ma¬ 
chine based on our earlier recommenda¬ 
tion might want to give the company a 
call at (617) 933-8442 to obtain a copy 
of the just released installation and op¬ 
eration manual for the Newton 286-12 
machine. Additional training courses 


Forms are similar to menus in that 
they also allow for the controlled display 
of data from a database or Workspace. 
They can also be designed with full¬ 
screen data entry fields. 

The Translate command lets you com¬ 
pile models, reports, graphs, application 
texts, and Screen Manager files. This can 
be useful for vertical-application devel¬ 
opers who wish to prevent their source 
code from being examined or distributed. 
Fully functioned applications requiring a 
runtime module can be distributed on 
three 5.25-inch diskettes — a significant 
disk space saving from the entire system 
(five disks). 


Summing up 

Strategic planning is an important ac¬ 
tivity for companies of any size. Deci¬ 
sion support systems now becoming 
available for microcomputers have 
proven effective for this complex task. 

By the same token, the electronic spread¬ 
sheet metaphor first developed for micro¬ 
computers is, for many applications, 
being stretched beyond its limit, some¬ 
times with damaging results. 

Spreadsheet users must begin to look 
past their easy-to-learn, most-favored 
computer tool to more appropriate finan¬ 
cial modeling products such as Micro¬ 
Simplan. To learn more about the prod¬ 
uct, contact Simplan Systems, 300 Eas- 
towne Dr„ Chapel Hill, NC 27514, 
phone (919) 493-2495. 
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have been added to their curriculum as 
well. Contact them at 100A Tower Of¬ 
fice Park, Woburn, MA 01801. 

— R. Eckhouse 

A powerful document-retrieval sys¬ 
tem. The world of electronically stored 
text documents is expanding very 
quickly, but the software for managing 
and retrieving these documents is lag¬ 
ging behind. Topic is an excellent but 
expensive ($8,000) document-storage 
and concept-based information-retrieval 
system produced by Verity, 1550 Ply¬ 
mouth St., Mountain View, CA 94043- 
1230, phone (415) 960-7600. 

Topic uses three kinds of information 
to determine the relevance of a topic to a 
document. The first is the relevance of 
each component subtopic. The second is 
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a relative weighing of the importance of 
each subtopic. The third combines all the 
evidence into a single relevance value. 

Topic is significant in offering a rule- 
based approach to full-text document re¬ 
trieval. The key distinction between 
Boolean query languages and Topic’s 
object-oriented query language is that the 
search object used with Topic is not a 
linear string of words, but a hierarchical 
outline describing the concept. For each 
user query, Topic will compute the de¬ 
gree of relevance of every document in 
the database and present the documents 
sorted by their relative score. Another 
feature I like is that Topic captures ex¬ 
pert knowledge as reusable objects. More 
specifically, it allows you to build named 
objects that know how to retrieve docu¬ 
ments about specific subjects. 

Topic works with documents produced 
by any of the popular word processing 
packages, optical character readers, and 
interfaces to most relational database 
management systems. It runs on IBM 
PCs and compatibles with MS-DOS and 
OS/2, Sun workstations, and a variety of 
minicomputers and mainframes with 
Unix or VMS. It also runs on networks 
consisting of Unix or VMS servers and 
Unix or DOS clients. It supports NFS, 
TCP/IP, and other standard network 
protocols. — M. Dediu 


Paste-in and pop-up notes. Tornado, 
whether stand-alone or RAM-resident, 
maintains collections of notes. It runs on 
MS-DOS systems and uses up to 60 
Kbytes of memory. You keep informa¬ 
tion in up to 50 linearly ordered piles of 
notes, each containing up to 500 notes. 
Each pile contains up to 54,000 charac- 

Notes are displayed in windows on the 
screen either in a “smart” overlapping 
mode or tiled. Using the disk commands, 
you load a pile into the primary memory 
buffer. You focus attention by explicitly 
selecting a note as “current.” Two types 
of command alter the focus: direct com¬ 
mands (go to the top, bottom, next, or 
previous note) and search commands. 
Once made the current note, a note can 
be edited, moved in the pile, deleted, 
written to any pile, or printed. 

I found Tornado effective and easy to 
use. You can record small notes and cap¬ 
ture screens quickly without losing your 
train of thought. The documentation is 
quite clear and complete. 

I found two aspects of Tornado troub¬ 
ling: the structure of the command inter¬ 
face and output control. 

Tornado is a $99.95 product of Micro 
Logic Corp., PO Box 70, 100 2nd St., 
Hackensack, NJ 07602, phone (800) 342- 
5930. — C. Kaman 
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Technology is Today’s Challenge 
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Some of the nation’s most exciting 
developments in software technol¬ 
ogy, supercomputer architecture, 
AI, and expert systems are under 
scrutiny right now at the Institute 
for Defense Analyses. IDA is a 
Federally Funded Research and 
Development Center serving the 
Office of the Secretary of Defense, 
the Joint Chiefs of Staff, Defense 
Agencies, and other Federal 
sponsors. 

IDA’s Computer and Software 
Engineering Division (CSED) is 
seeking professional staff members 
with an in-depth theoretical and 
practical background in software 
engineering tools, techniques, and 
theories. One emphasis of the Div¬ 
ision’s work is on defining, build¬ 
ing, and evaluating tools/envir¬ 
onments to support the entire 
software life-cycle of mission criti¬ 
cal computer based systems, 
focused on Ada and artificial intel¬ 
ligence environments. Tasks 
include efforts in prototyping 
tools/systems, testing and evaluat¬ 
ing support tools, advising major 
DoD programs on appropriate 
technologies, and assisting the 
DoD in defining advanced policies 
for software development and 
maintenance. 

Specific desired interests and skills 
include: 

• Formal representation of 
requirements and designs 

• Program verification, test and 
evaluation 

• Combined hardware/software 
system design methodologies 

• Transformational approaches to 
automated program generation 

• Software reusability and reuse 


• Software reliability/fault 
tolerance 

• Environment test and eval¬ 
uation (including assessing 
impacts on productivity and 
reliability) 

• Standards for environmental and 
operational software interfaces 

Specialists in other areas of Com¬ 
puter Science are also sought: Dis¬ 
tributed Systems, Artificial Intelli¬ 
gence and Expert Systems, 
Programming Language Experts 
and Computer Security Scientists. 

We offer career opportunities at 
many levels of experience. You 
may be a highly experienced indi¬ 
vidual able to lead IDA projects 
and programs... or a recent 
MS/PhD graduate. You can 
expect a competitive salary, excel¬ 
lent benefits, and a superior pro¬ 
fessional environment. Equally 
important, you can expect a role 
on the leading edge of the state of 
the art in computing. If this kind 
of future appeals to you, we urge 
you to investigate a career with 
IDA. Please forward your resume 
to: 

Mr. Thomas J. Shirhall 
Manager of Professional Staffing 
Institute for Defense Analyses 
1801 N. Beauregard Street 
Alexandria, VA 22311 
An equal opportunity employer. 
U.S. Citizenship is required. 
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NEW PRODUCTS 


Contact or send releases to Nancy Hays, Computer, 10662 Los Vaqueros Circle, Los Alamitos, CA 90720; Compmail+, n.hays 


NCR adds Unix-based Tower PC-based test equipment analyzes digital logic 


NCR has released the Tower 32/825, 
a Unix-based computer. The new sys¬ 
tem supports a maximum of 256 users 
and 128 Mbytes of memory. The 10-slot 
cabinet has from one to six application 
processors, each using a 30-MHz 
Motorola 68020 microprocessor with 40 
Kbytes of cache memory and Motorola 
68882 floating-point coprocessors. 

According to the company, the sys¬ 
tem features a plug-in design for inte¬ 
grated disk and tape units. This 
reportedly eliminates cabling and facili¬ 
tates upgrades or repairs. 

An entry-level configuration of the 
Tower 32/825 costs $98,160. 

Reader Service 30 


Heath/Zenith Computer Based 
Instruments has added two PC-based 
digital logic analyzers to its line of test 
equipment. The 32-bit ST-4800 and 
16-bit ST-4750 logic analyzers report¬ 
edly aid in testing and debugging hard¬ 
ware and software at sample rates up to 
50 MHz. Both systems have dual sam¬ 
ple memories, each with 4,000 bits of 
storage per channel. 

The systems have internal clocking 
from 20 nanoseconds to 40 milliseconds 
in either state or timing mode. An exter¬ 
nal clocking feature provides for syn¬ 
chronous testing. Both units trigger 
internally on any pattern of up to 16 
channels. External triggering offers 
pulse widths as low as 10 nanoseconds, 


with a choice of either leading or trail¬ 
ing edge. 

The digital logic analyzers operate 
with other computer-based instruments 
through Versatile Instrument Operating 
Software, or VIOS. 

Both state and timing modes offer 
search capability and built-in printer 
drivers. The timing mode features dual 
cursors with zoom, while the state mode 
features a built-in pattern recognizer 
that permits displays of user-defined 
mnemonics instead of specified bit 
patterns. 

Contact the company for pricing. 

ST-4800: Reader Service 32 
ST-4750: Reader Service 33 


RISC computer uses BCS for software 


Sanyo/Icon has based the Model 
8000 computer on Motorola’s 88000 



Sanyo/Icon’s Model 8000 minicom¬ 
puter employs Motorola’s 88000 RISC 
chip and the 88open Binary Compatibil¬ 
ity Standard. 


RISC chip and the 88open Binary Com¬ 
patibility Standard for software. The 
BCS calls for software written for any 
88000-based computer to employ a 
common interface to executable or 
binary programs. 

According to the company, the 
Model 8000 combines the 32-bit proces¬ 
sor with two-bus Harvard architecture 
supporting independent 32-bit instruc¬ 
tion and data buses. Three parallel sub¬ 
systems take over work normally 
executed by the CPU, reducing traffic 
on the system bus. The three processors 
communicate with their associated 
memory on a separate local bus. 

The Model 8000 employs three oper¬ 
ating systems: MS-DOS, Unix, and 
Pick. It supports up to 256 users and 
reputedly delivers up to 15 million 
instructions per second. The base con¬ 
figuration has a 20-slot backplane that 
permits system expansion to 128 serial 
ports and 32 Gbytes of disk storage. 

A 64-user Model 8000 with 350 
Mbytes of disk storage, 14 Mbytes of 
memory, and 64 RS-232 ports costs 
$155,000. 


Reader Service 31 


CAD/CAM/CAE software 
runs on Unix-based 
workstations 

CADAM’s computer-aided design, 
manufacturing, and engineering soft¬ 
ware, the second generation of Profes¬ 
sional CADAM, runs on 32-bit 
Unix-based workstations from Apollo, 
Sun Microsystems, and IBM. The com¬ 
pany claims to have developed a uni¬ 
form edition of its core application and 
isolated hardware-specific code in a 
modifiable portion of the program 
called Power Link. 

CADAM has also announced a new 
version of its printed circuit board 
design software for 32-bit Unix work¬ 
stations. Professional CADAM Prance 
is a CAD package for PCB design and 
manufacture. It consists of three mod¬ 
ules. Professional CADEX provides 
schematic capture and netlist extrac¬ 
tion. Professional CADPC has interac¬ 
tive layout and placement. CADAM 
Prance features automatic placement 
and routing. 

Contact the company for more infor¬ 
mation and for pricing. 

Professional: Reader Service 34 
Prance: Reader Service 35 
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DEC adds new RISC-based general-purpose computer 


Digital Equipment has added the 
DECsystem 3100 general-purpose com¬ 
puter to its family of RISC-based Unix 
computer systems. The new system 
incorporates the R2000 and R2010 
RISC chips from MIPS Computer 
Systems. 

The DECsystem 3100 is configurable 


to support from four to 64 users. Sys¬ 
tem memory is expandable in 4-Mbyte 
increments to a total of 24 Mbytes. 
Configurations include licenses for the 
Ultrix operating system, TCP/IP, NFS, 
DECwindows/X Windows System, and 
an optimizing C compiler. 

A four-user system with 8 Mbytes of 


IBM expands AS/400 family with new model, 
additional memory 


Intel i860 holds more than 
1 million transistors 

The 64-bit i860 RISC microprocessor 
from Intel contains more than 1 million 
transistors and performs up to 80 mil¬ 
lion calculations per second, according 
to the company. The chip reportedly 
targets multiprocessing systems, 3D 
workstations, and graphic subsystems. 

The i860 contains integer and 
floating-point graphics units, a memory 
management unit, and instruction and 
data caches. It is manufactured using 
the company’s CHMOS IV one-micron 
process. 

Samples of the 33-MHz processor are 
available now, with production sched¬ 
uled for the third quarter. Samples of 
the 40-MHz processor will be available 
in the third quarter. A military version 
is scheduled for 1990. 

The i860 will cost $750 for a 33-MHz 
version in 1,000-piece quantities. 

Reader Service 37 


Apple bases Mac IICX 
on 68030 

Apple Computer has announced the 
Macintosh IICX featuring Motorola’s 
16-MHz 68030 and 68882 microproces¬ 
sors, three NuBus expansion slots, and 
Apple’s SuperDrive, which allows 
access to non-Macintosh disks. The new 
model also has an automatic restart 
feature. 

The Macintosh IICX comes with 
from 1 to 8 Mbytes of RAM on the 
logic board, standard Macintosh ports, 
an external floppy disk drive port, a 
mouse, System Software 6.0.3, Hyper¬ 
Card Software, and documentation. 

A configuration with 1 Mbyte of 
RAM and the SuperDrive costs $4,669. 
A configuration with 4 Mbytes of RAM 
and an 80-Mbyte hard disk drive with 
A/UX installed costs $7,552. 


IBM has enhanced the Application 
System/400 family with an expansion 
unit for the Model B20, additional 
memory capacity for Models B10 and 
B20, and the new high-end Model B70. 

The B20 expansion unit reportedly 
allows users to add disk storage, com¬ 
munications lines, and other devices. It 
consists of an internal I/O bus, a mag¬ 
netic storage controller, and five avail¬ 
able card slots. It attaches to the main 
system unit with three cables. The B20 
expansion unit, scheduled for June 
availability, costs $9,800. 

Model B10 now comes with a maxi¬ 
mum 16 Mbytes of main memory, while 
Model B20 comes with a maximum of 


memory and a 332-Mbyte disk drive 
costs $20,400. A 32-user system with 24 
Mbytes of memory and three 
332-Mbyte disk drives costs $55,604. 

The DECsystem 3100 is scheduled for 
volume deliveries by June. 

Reader Service 36 


28 Mbytes of main memory. The 
4-Mbyte main memory cards and the 
4-Mbyte main memory expansion cards 
cost $6,000 each. The higher memory 
models are scheduled for June. 

The new Model B70 is field- 
upgradable from other high-end 
AS/400 models. It features a new 
16-Mbyte main storage card. The B70 
costs $310,000. The OS/400 processor- 
based charge is $69,000. The 16-Mbyte 
main memory card costs $24,000. The 
B70 is scheduled for June delivery. 

Expansion: Reader Service 39 
B10/B20: Reader Service 40 
B70: Reader Service 41 



The expansion unit for IBM’s AS/400 Model B20 allows users to add disk storage, 
Reader Service 38 communications lines, and other devices. 
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Bull adds two models to XPS-100 family 


Bull HN Information Systems has 
announced the addition of two new 
models to its Unix-based XPS-100 
family of multiuser computers. The 
X-25 supports from 12 to 72 users and 
the X-45, from 12 to 144 users. The sys¬ 
tems incorporate a 25-MHz Motorola 
68020 microprocessor, 256 Kbytes of 
EPROM for diagnostics and initializa¬ 
tion, and a custom MMU. 

The new systems run Bull’s version of 
AT&T Unix System V, Release 3. 

The midlevel Model X-25 has 4 
Mbytes of main memory expandable to 
16 Mbytes. It is field-upgradable to the 
dual-processor X-45. Model X-45 has 8 


Mbytes of main memory expandable to 
32 Mbytes. Both models feature an inte¬ 
grated disk, tape, and disk controller; a 
720-Kbyte or 1.2-Mbyte MS-DOS and 
OS/2 compatible 5/-inch disk drive; 
and a 60-Mbyte streamer tape unit. 

The X-25 costs $32,670. A 32-user 
X-25 with 8 Mbytes of memory and 650 
Mbytes of fixed disk storage costs 
$47,120. The X-45 costs $54,170. A 
72-user X-45 with 24 Mbytes of memory 
and 975 Mbytes of fixed disk storage 
costs $95,020. 

X-25: Reader Service 42 
X-45: Reader Service 43 



Bull HN’s XPS-100 Model X-25 runs 
the Unix operating system. 


Software extracts FET parameters 


EEsof’s Xtract software performs 
linear and nonlinear modeling 
characterization of microwave and 
radio-frequency gallium arsenide 
field-effect transistors. The soft¬ 
ware also performs nonlinear FET 
parameter extraction. 

Xtract works with the company’s 
computer-aided test program, Anacat. 
Anacat acquires the measurement data 
used by Xtract for FET modeling 
characterization. It collects s-parameter 
data from vector network analyzers and 
DC I-V data from semiconductor 
parameter analyzers. 

Xtract generates transistor characteri¬ 
zation files for EEsof’s Bias-Dependent 
Transistor Model and other FET 
models. You can graphically compare 


modeled results with original measure¬ 
ments, tune circuit model parameters 
on screen, and view changes in the 
simulated results. 

Xtract also provides custom models 
for foundry devices. 

First available in the fourth quarter 
of 1988, Xtract runs on PCs under MS- 
DOS, PC-DOS, and OS/2; systems 
from Apollo, Sun Microsystems, and 
Digital Equipment; and HP 9000 series 
300 machines. 

Xtract’s price of $34,500 varies 
according to configuration and options. 
The price includes Anacat version 1.2, 
the Xtractor Engine, EEsof’s FET Ker¬ 
nel, and training. 
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Workstation uses 68030 

Gerber Systems Technology has 
added the Sabre SH5340 model to its 
Sabre-5000 series of engineering work¬ 
stations. The desktop workstation uses 
the Motorola 68030 microprocessor and 
Unix. 

SH5340 can be configured as a disk¬ 
less work node or with a dedicated hard 
disk. Applications software and user 
data files are compatible with those of 
other Sabre-5000 systems. 

The SH5340 as a turnkey system 
including hardware and software ranges 
in price from approximately $26,000 to 
$45,000 according to options selected, 
particularly the graphics display unit 
chosen. 

Reader Service 45 


Desktop workstation is Sun compatible 



Solbourne’s Series4/500 desktop work¬ 
station comes in a diskless, dataless, or 
stand-alone configuration. 


Solbourne Computer claims that its 
desktop workstation, the Series4/500, is 
binary and network compatible with 
Sun Microsystems’ Sun-4 workstations. 
According to the company, the 
Series4/500 provides 9.5 million 
instructions per second with a single 
processor or 17 MIPS with an optional 
second processor. 

The new system incorporates the 
company’s proprietary 64-bit internal 
bus, the Kbus, which operates at 128 
Mbytes per second. The processors (two 
maximum) use Fujitsu’s SF9010IU 
Sparc RISC chip and Weitek’s floating¬ 
point chip set. 

The Series4/500 comes in three basic 
configurations: a diskless model for use 


on a network; a dataless configuration 
that includes one 3J(-inch hard disk 
drive to hold a local copy of SunOS and 
for local swap space; and a stand-alone 
model with SCSI hard-disk storage and 
tape storage. 

The single-processor Series4/501 
costs $19,400 (diskless), $22,100 (data¬ 
less), or $27,500 (stand-alone). The 
dual-processor Series4/502 costs 
$25,400 (diskless), $28,100 (dataless), or 
$33,500 (stand-alone). Prices include a 
19-inch monochrome display (add 
$6,500 for a color display), keyboard, 
mouse, installation, a one-year war¬ 
ranty, and a year of customer support. 

Reader Service 46 
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HCL bases multiprocessor Unix minicomputer on 68030 


HCL America has announced the 
M3000 series of Unix-based multipro¬ 
cessor minicomputers, built around 
Motorola’s 25-MHz 68030 processor 
and optional 68882 math coprocessor. 
The systems come with from one to six 
CPUs with performance ranging from 4 
to more than 15 million instructions per 
second. 

The architecture uses a single global 
shared memory with two-way interleav¬ 
ing. The proprietary HMP (High-speed 
Multi Processor) bus handles transfers 
between CPUs and memory, while the 
VMEbus handles peripheral I/O. 


According to the company, peripheral 
processors handle disk, tape, terminal, 
and network I/O to relieve CPU 
overhead. 

The M3000 runs under HCL’s Mag- 
nix V.3 operating system, an implemen¬ 
tation of AT&T Unix System V.3. The 
Magnix V.3 TCP/IP implementation 
supports Ethernet, X.25, and other net¬ 
working protocols. Magnix V.3 also 
supports a variety of language com¬ 
pilers and programming utilities. 

Configurations range from the low- 
end single-processor M3010 with 64 
Kbytes of cache memory, 4 Mbytes of 


RAM, support for 16 users, 2.16 Gbytes 
of disk storage, and 60 Mbytes of car¬ 
tridge tape storage to the high-end six- 
processor M3060 with 64 Mbytes of 
RAM, support for 128 users, 6.5 Gbytes 
of disk storage, and 145 Mbytes of car¬ 
tridge tape storage. 

An M3000 system with two CPUs 
running at 25 MHz, 8 Mbytes of mem¬ 
ory, a 145-Mbyte hard disk drive, a car¬ 
tridge tape drive, eight asynchronous 
ports, and the multiprocessor operating 
system costs $23,000. 
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Updated Precise 3.0 software analyzes and simulates circuits 


Electrical Engineering Software has 
updated its Precise interactive analog 
circuit analysis and simulation software 
with release 3.0. Features added include 
integration with EES’ device characteri¬ 
zation product, circuit design optimiza¬ 
tion and expert system options, more 
models, and a new menu interface. 

Precise 3.0 runs on systems from Sun 
Microsystems, IBM, Apollo, Digital 
Equipment, Cray, and Alliant. Prices 
start at $9,500. 

Precise, first introduced in June 


1984, includes parametric, Monte 
Carlo, mixed domain, analog/digital, 
worst case, and environmental effects 
modeling. Precise 3.0 features integra¬ 
tion with Suxes 20 device characteriza¬ 
tion software; this reputedly guarantees 
compatibility between model equations 
used in device modeling and simulation 
model equations. 

The circuit design optimization fea¬ 
ture allows you to specify the desired 
circuit response. The software then pro¬ 
vides the optimal parameter values 


needed to achieve the specified results. 

The expert system option allows you 
to implement specific design actions 
using rules from the software’s knowl¬ 
edge base. You can also add your own 
information to the knowledge base. 

A built-in self-help function provides 
program assistance. The user interface 
features color graphics and menu- 
driven interactive control on the Sun 
platform. 
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Software development tools 
target 88000 

Oasys offers a set of software devel¬ 
opment tools for Motorola’s 88000 
RISC family. Oasys 88K Tools consists 
of C, Pascal, and Fortran native and 
cross compilers; a native and cross 
assembler/linker, a symbolic debugger, 
and the 88000 simulator developed by 
Motorola. 

The tools run on DEC’S VAX sys¬ 
tems, Sun’s Model 3 series, Apple’s 
Macintosh II computers, and Motor¬ 
ola’s VME Delta platforms. They also 
run on 88000-based systems. 

The tools comply with the Binary 
Compatibility Standard developed by 
the 88open Consortium. 

Oasys 88K Tools costs $15,500 for 
the VAX, $9,500 for the Sun 3 and 
Delta series, and $4,000 for the 
Macintosh. 
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Four new models join Power 6 family 


Computer Consoles’ Computer 
Products Division has added four 
models to the Power 6 family of Unix- 
based minicomputers with the midrange 
L-Series. According to the company, 
the Power 6/32 LB, Power 6/32 LE, 
Power 6 / 32 L, and Power 6 / 32 LX provide 
from 3 to 8 millions of instructions per 
second of processing power. 

The L-Series reportedly includes 
upgrades from the current S-Series: 
triple the cartridge drive capacity, two 
additional card slots, a choice of 380- or 
760-Mbyte disk drives, and support for 
SCSI. 

The LE, L, and LX offer 3, 5, and 8 
MIPS processors, respectively; 32 ports 
upgradable to a total of 192; and 8 or 
16 Mbytes of memory upgradable to 64 
Mbytes. All include a 150-Mbyte car¬ 
tridge tape drive and an option for reel- 
to-reel tape storage. The LB is a 
minimally configured 3 MIPS machine 


with 4 Mbytes of memory and 16 ports. 
Prices start at $50,000. 
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puters is object-code compatible with 
other computers in the Power 6 family. 
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Stimulator tests RISC line gets multiprocessor boards 

VMEbus responses 


Concise Technology offers the 
CVMEBS1 VMEbus Stimulator. The 
bus-specific diagnostic tool plugs 
directly into a VMEbus backplane. Sys¬ 
tems designers and integrators can 
insert normal and abnormal stimuli 
directly onto the bus, under manual 
control. The unit conforms to VMEbus 
Specification Revision C.l. 

Push-button switches on the front 
panel permit selection of the signal to 
be asserted. Where applicable, the sig¬ 
nal will remain asserted until the rele¬ 
vant handshake is received. LEDs 
indicate status. For interrupts, the unit 
provides a user-selectable status ID to 
the system as the handshake proceeds. 

The CVMEBS1 provides a VME 
mode and slow and spur modes. The 
slow mode uses a slow pace to permit 
close monitoring of VMEbus operation. 
The spur mode permits generation of 
spurious interrupts or bus requests. 

The bus stimulator requires one slot 
in the system. It works alone or with the 
CVMEBM1 Bus State Monitor. 

The CVMEBS1 costs $1,995. 
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Concise Technology’s CVMEBS1 Bus 
Stimulator plugs into a slot in the VME¬ 
bus backplane to test system bus 
responses. 


Motorola Microcomputer Division 
has added the MVME188 series of 
multiprocessor boards to its RISC prod¬ 
uct line. According to the company, the 
RISC boards will provide from 15 to 60 
million instructions per second of pro¬ 
cessing power with 128 Kbytes of cache 
and 16 to 64 Mbytes of shared main 
memory in a standard VMEmodule 
board set. 


Motorola’s Computer Group has 
announced the Delta Series 8000 family 
based on the company’s 88000 RISC 
processor. According to the company, 
AIM III benchmark tests have shown 
the single-processor Model 8864SP to 
be capable of operating at 25 MHz 
while supporting up to 170 users. 

The new computers incorporate 
Motorola’s Hypermodule integration 
package, which reportedly allows up to 
four 88100 RISC processors on a single 
board. 

The Delta Series 8000 uses the System 
V/88 operating system, the company’s 
derivative of Unix System V Release 3. 
The series complies with the Binary 
Compatibility Specification and System 
V Interface Definition. 

Delta Series 8864 models are 20-slot 


The single-processor MVME188, 
available in May, costs $22,950 in 
100-piece quantities. The dual- and 
quad-processor versions, available in 
June, will cost $27,200 and $33,500, 
respectively, in 100-piece quantities. 
(Prices are for 128-Kbyte cache and 
16-Mbyte DRAM models.) 
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systems with one to four 20-MHz 
MC88100 RISC microprocessors, 128 
Kbytes of cache memory, 16 to 64 
Mbytes of main memory, one to four 
SCSI Winchester disk drives, a 
150-Mbyte streaming tape drive, and 
performance of 17 to 50 MIPS. A 
single-processor 8864SP costs $52,940; 
a dual-processor 8864DP, $69,940; and 
a quad-processor 8864QP, $80,190. 

Delta Series 8608 models are 12-slot 
systems with a single 20-MHz 88100, 32 
Kbytes of cache memory, 8 to 32 
Mbytes of main memory, one to four 
SCSI Winchester disk drives, 150 
Mbytes of streaming tape storage, and 
performance of 17 MIPS. Prices start at 
$27,935 for one unit. 
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Motorola’s MVME188 provides a RISC multiprocessor on a board. 


Delta Series built around 88000 RISC processor 


COMPUTER 











Call For Papers 


PARBASE-90 

A Two-Track International Conference on Databases, Parallel Architectures, and their Applications 
Miami Beach, Florida - March 7 - 9, 1990 

Sponsored by Florida International University in cooperation with Euromicro 


General Chair: 

D. Tal - FIU 

Scope 

Parbase-90 will provide a forum for exchange of information between scientists and engineers in the 
fields of theory, design and applications of databases and/or of parallel computer architectures. We 

European Chair: 

N. Wiseman - Cambridge Univ. 

(U.K.) 

solicit both theoretical and applied papers reporting important developments or experience. Proposals 
for tutorials and panels are also welcome. A keynote speech will be given by Prof. C.A.R. Hoare. Pre¬ 
conference tutorials and two panel sessions on parallel architectures and on databases will be offered. 
An industrial exhibition will be held. Proposed industrial sponsors and exhibitors are invited to contact 

Program Committee: 

the conference organizers. 

Chairpersons: 

N. Rishe - FIU 

S. Navathe - Univ. of Florida 

Topics 

- parallel and distributed computation and architectures (category 1) 

- special purpose parallel systems (2) 

N. Adam - Rutgers Univ. 

M. Ahuja - Ohio State Univ. 

B. Berra - Syracuse Univ. 

B. Bhargava - Purdue Univ. 

P.P.S. Chen - Louisiana State Univ. 

K. Dittrich - Univ. of Karlsruhe 

(FRG) 

R. Elmasri - Univ. of Houston 

I. Erenyi - Acad. Sciences Hungary 

E. Fernandez -Florida Atlantic 

Univ. 

O . Frieder - Bell Com. Research 

B. Furht - MODCOMP 

S. Gadia - Iowa State Univ. 

E. Gudes - Ben-Gurion Univ. 

(Israel) 

H. Kangassalo - Univ. of Tampere 
(Finland) 

R. Liuzzi - Rome Air Development 
Center (USA) 

A. Pelin - FIU 

N. Prabhakaran - FIU 

C. Pu - Colombia 

A. Sheth - Unisys, Inc. 

P. Shoval - Ben-Gurion Univ. 

(Israel) 

G. Silberman - Carnegie-Mellon 

Univ. 

A. Solvberg - Univ. of Trondheim 
(Norway) 

D. Tabak - George Mason Univ. 

R. Varadarajan - Univ. of Florida 

N. Wiseman - Cambridge Univ. 

(U.K.) 

- distributed systems (3), including fault tolerance (3B) and design (3C) 

- technology and applications of supercomputers (4) and fifth generation computers (4B) 

- advanced novel technology and applications (5), including massively parallel systems (5B) 
database machines (6) 

- development of large databases (7), including semantic modeling (7B) and database design (7C) 

- other topics relevant to the goals of the conference (8) 

Paper Submission 

For regular papers the authors should submit 5 copies of the full text (2500-6000 words including a short 
abstract). In order to permit anonymous review, the names and addresses of the authors should appear 
not on the paper itself but on a separate sheet, together with the title of the paper, category (1 -8) and 
five keywords. The authors of short papers should submit 2 copies of an abstract of up to 500 words. 
All accepted papers will be published in the proceedings. Short papers will be published in a 600 - 2000 
word format. Papers submitted as regular but not accepted as such will be automatically considered 
for the short paper sessions. Selected best papers will be published in the journal Data and Knowledge 
Engineering and in the Euromicro journal Microprogramming and Microprocessing. 

Contributions should be mailed to: 

Regular papers from Europe: Tutorial proposals: All other papers, panel & 

Dr. Neil Wiseman Dr. B. Furht exhibit proposals: 

Computer Laboratory MODCOMP PARBASE-90 

Cambridge University 1650 West McMab Rd. School of Computer Science 

Cambridge CB2 3QG Ft. Lauderdale, FL 33340 Florida International University 

E-mail: new1@uk.ac.cam.cl (305)974-1380 Miami, FL 33199 

44(0223)334657 E-mail: parbase@servax.bitnet 

(305)554-3429 

Deadlines 

• Proposals for tutorials and regular papers received - August 4, 1989 
•Abstracts of short papers received - October 27, 1989 
•Authors notified - November 24,1989 

•Regular and short papers in camera-ready form received - January 1,1990 







Company, Model, Function 

Comments R.S. No. 

AT&T Microelectronics 
T7121 HIFI-64 

ISDN chip 

An HDLC interface chip for ISDN, for B-channel or D-channel data transport. Connects 120 

serial communications links to 8-bit micros. Operates in basic rate and primary rate ISDN 
environments. Comes in a 28-pin plastic DIP or plastic SOJ. Samples in May. Cost: $12. 

Fujitsu Microelectronics 
MB814100 

DRAM 

A 4-Mbit DRAM configured 4M x 1. Comes in an 18-lead plastic DIP, 20-lead plastic zig- 121 

zag in-line, and 20- or 26-lead plastic SOJ packages in 300 and 350 mil widths. Available in 
engineering samples. Cost: $380. 

Integrated Device Tech¬ 
nology 

IDT10494, IDT 100494 
SRAMs 

Two 64K ECL I/O SRAMS operating at 8-ns access times. Organized 16K x 4. Built using 122 

BiCEMOS II. Come in 400-mil sidebraze packages. Available as samples, with production 
in the third quarter. Cost (100s): $109.60 for IDT10494, $121 for IDT100494. 

Integrated Device Tech¬ 
nology 

IDT79R3000 

Military RISC CPU 

A military version of the IDT79R3000 RISC microprocessor. Operates at 16.7 MHz and 123 

performs at a sustained rate of 12 MIPS. Manufactured in CEMOS IV. Comes in a 
ceramic PGA. Production scheduled for Oct. 1989. Cost (100s): $720. 

Inmos 

IMS G300 CVC 

CVC 

A color video controller consisting of a 256 X 24-bit color look-up table, a programmable 124 

video timing generator, a 32-bit multiplexed pixel port, a triple video DAC with 8-bit reso¬ 
lution, and phase-locked loop. Comes in an 84-pin PGA or quad cerpac. Cost (1,000s): 

$101.14; $175 for engineering parts. 

Intel 

5AC324 

EPLD 

A 24-macrocell, CHMOS erasable programmable logic device. Has 10 programmable 125 

inputs and 24 configurable I/Os. Permits definition of macrocells allocated with zero to 16 
product terms. Cost (1,000s): $27 for 40-pin ceramic DIP, $24 for 44-pin PLCC. 

Motorola 

MCM6270 

SRAM 

A 4K x 4 SRAM with output-enable access times of 12 ns for the 25-ns part and 14 ns for 126 

the 35-ns part. Comes in a 24-lead, 300-mil SOJ package (MCM6270J25/35) and 22-lead, 

300-mil plastic DIP (MCM6270P25/35). Cost (100s): $6.90 for MCM6270J25, $5.18 for 
MCM6270J35. 

Samsung Semiconductor 
KM75C01A, KM75C02A 
FIFOs 

Parallel FIFO dual-port buffer memories organized 512x9 bits (01 A) and 1,024 x 9 bits 127 

(02A). Have access times of less than 25 ns and can operate at 40 MHz. Come in 28-pin 
plastic DIPs or 32-pin PLCCs. Cost (1,000s): $14 for 01 A, $18 for 02A. 

Sodima 

KIM 

RISC chip 

A VLSI chip for embedded real-time applications. Executes instructions at up to 20 MIPS, 128 
based on a clock speed of 20 MHz. Running KOS (Knowledge-based Operating System), 
fires up to 3,600 rules/s. Comes in a 176-pin PGA. No price given. 

Texas Instruments 
TMS27PC128FML/ 
256FML/512FML 
OTPROMs 

A family of one-time programmable ROMs in surface-mount PLCCs. TMS27PC128FML 129 

is 128K, TMS27PC256FML is 256K, and TMS27PC512FML is 512K. Pin- and upgrade- 
compatible with mask-programmed ROMs. Cost (1,000s): $5.20 for 128K, $5.45 for 256K 
$9.85 for 512K. 

Vitesse Semiconductor 
VCB50K family 

Standard cell library 

A standard cell library for ECL or GaAs product design. Doubles the integration level to 130 

22,000 gates. Optimized for performance at clock rates up to 3.5 GHz. Cost: typically 
from $30,000-$125,000 for nonrecurring engineering costs and production pricing from 
$20-$800 for commercial grade. 

Weitek 

Abacus 3168 

Math coprocessor 

A floating-point coprocessor for the Motorola 68020 and 68030 microprocessors at clock 131 

rates of 20, 25, and 33 MHz. Has a floating-point multiplier, an ALU, and a 
divide/square-root unit. Production in Sept. 1989. Cost (2,500s): $499 (25-MHz chip); 

$995 for daughterboard (April). 

Yamaha 

EPDC 

Graphics controller 

An EGA-compatible panel and display controller for laptop computers. Controls color and 132 
B/W electroluminescent, plasma, and liquid crystal displays, plus raster scan CRT dis¬ 
plays. Maintains true aspect ratio. Cost (100s): $40. 

Zilog 

Z16C30 

use 

A universal serial controller with a 10 Mbit/s data transfer rate. Uses a 32-byte FIFO 133 

buffer. Supports DMA fly-by mode transfers. Two full-duplex channels, each supporting 

10 protocols and 8 data encoding formats. Two independent interrupt lines on each chan¬ 
nel. Cost (100s): $105 for samples. 
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I FAT - Institute For Advanced Technology 



SERIES OF STATE-OF-THE-ART COURSES 

Sponsored by the IEEE South Florida Section 

Fontainebleau Hilton Resort and Spa, Miami Beach, FL 


May 1-3, 1989: 

CE101 NEURAL COMPUTERS: CONCEPTS, APPLICATIONS AND IMPLEMENTATIONS 

Program Director and Speaker: Prof. O.K. Ersoy (Purdue University) 

May 8-10, 1989: 

CE102 DESIGN AND PERFORMANCE EUALUATI ON OF PARALLEL COMPUTER SVSTEMS 

Program Director: Dr. D. Vrsalovic (Carnegie-Mellon University) 

Speakers: D. Siewiorek (CMU), D. Vrsalovic (CMU), K.S. Trivedi (Duke) 

May 15-17, 1989: 

CE103 ADUANCES IN RISC PROCESSOR TECHNOLOGV 

Program Director: Prof. D. Tabak (George Mason University) 

Speakers: V. Oklobdzija (UC Berkeley), D. Tabak (GMU), V. Milutinovic (Purdue) 

May 22-24, 1989: 

CE104 INTELLIGENT MANUFACTURING SVSTEMS 

Program Director and Speaker: Prof. S. Ahmad (Purdue University) 

May 29-31, 1989: 

CE105 SUPERCOMPUTERS: ARCHITECTURES AND APPLICATIONS 

Program Director: Dr. A.R. Hurson (Penn State University) 

Speakers: A.R. Hurson (Penn State), K. Kavi ( U. of Texas), B. Furht (MODCOMP) 

WHO SHOULD ATTEND: System designers, design engineers, managers, research scientists, college 
professors, and advanced graduate students 

IEEE Members Non-IEEE Members 

Early registration (three weeks before a course): $745 per course $795 per course 

Late registration: $845 per course $895 per course 

Multiple registrations from the same organization 10% discount 

Limited enrollment for maximal interaction with speakers, recognized experts in their fields 
Registration fee includes course participation, a copy of the textbook, and a copy of all transparencies 
Special arrangement with Fontainebleau Hilton (305/538-2000): $98 per night 


REGISTRATION FORM 


TITLE OF THE COURSE . 



Make checks payable to IFfiT Send to: IFfiT, P.0. Boh 163141, Miami, Florida 33116-3141 
Telephone: (305) 388-1940, Facsimile: (305) 388-1940 
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Company, Model, Function 


Comments 


Ciprico 
Rimfire 3550 
HBA 

Datatech 

PC, PS/2 Liberator 
Modems 

Force Computers 
CPU-23 

Board computer 

General Micro Systems 
GMS V17 
Board computer 

MemTech Technology 

PCB-74 

Memory board 

Paramax 

PS-1 

Transputer board 

Racal-Vadic 

2400/PS 

Modem 


A host-bus adapter VMEbus board supporting SCSI-2. Supports data transfers of 8, 16, 135 

and 32 bits; tagged commands; and max SCSI-2 data transfer rates of 20 Mbytes/s syn-’ 
chronous and 8 Mbytes/s asynchronous. Shipments in May. Cost: $1,695. 

Card modems for IBM PCs and PS/2s and compatibles. Offer V.21, V.22, and V22 bis 136 
standards. Feature MNP Class 5 error correction and data compression, self-test, and 
remote diagnostics. Cost: £495 for PC Liberator, £595 for PS/2 Liberator. 


A 32-bit, 68020-based, VMEbus single-board computer with message-passing capabilities 
implemented in an application-specific gate array that enables multiprocessing. Comes with 
VMEPROM software. Cost: $4,990 (12.5 MHz) or $5,990 (25 MHz) 


A 32-bit, 68030-based, VMEbus CPU card with VMEPROM software, a 68882 coproces- 138 
sor, up to 1 Mbyte of SRAM, up to 256 Kbytes of EPROM, two multiprotocol serial ports, 
and a configuration controller with timers. Runs at 33 MHz. Cost: $1,813. 


A bubble memory board providing 512 Kbytes to 4 Mbytes of nonvolatile storage, depend- 139 
ing on the number of SBM-74 standard bubble modules mounted on the board (up to 
eight). Emulates a hard disk drive using MS-DOS or PC-DOS. Cost: $250 


A 1-Mbyte four-cycle ParaSIMM, or transputer daughter board, with Inmos’ T800-20 140 

transputer processor. Has a software rating of 3.75 MWhetstones/s nominal. Measures 
3.5 x 1.95 x .225 inches. Fits into 30-pin SIMM memory module mechanical format. Cost: 


An asynchronous, V.22 bis, 2400-bps modem with auto-dial and auto-answer for the IBM 141 
Micro Channel Bus. Compatible with Hayes AT command set. Provides MNP error con¬ 
trol for Classes 2-4, compatible with CCITT V.42 error control. Has built-in diagnostics 


Radstone Technology 

SCSI-11 

HBA 


Seattle Telecom & Data 

STD-386CP 

Motherboard 


An SCSI host-bus adapter board with a VMEbus and VSB interface. Permits independent 142 
operation of the buses. Also has APEX (Advanced Processor Extension) bus architecture 
Has a master/slave VSB interface with its own DMA. VTC’s VIC068 chip handles VME¬ 
bus DMA and arbitration. Cost: $2,195. 

An 80386 motherboard for the Compaq 8086 Deskpro. Requires no system reconfiguration 143 
or software installation. Supports MS-DOS, OS/2, Unix, Xenix, PC/MOS, and Concur¬ 
rent DOS. Configured with eight expansion slots in 16- or 20-MHz versions with 1, 2, 4, 8, 
or 16 Mbytes of memory. Cost: with 1 Mbyte of memory, $1,645 (16 MHz) or $2,095 (20 ’ 


Sun Microsystems 
FPU2 

Floating-point accelerator 

Touchbase Systems 
WorldPort 2496 
Portable fax/modem 


Ven-Tel 
Mac2400E 
Modem card 


A floating-point accelerator for Sun-4 workstations. Includes a gate-array controller and 
the Texas Instruments 8847 floating-point processor. Fits into a socket on the Sun-4 CPU 
board. Will replace the current FPU. Cost: $3,000 as a separate option. 

A battery-powered portable combining a 9600-bps Group III facsimile modem with a 
2400-bps data modem. Has two standard RJ11 jacks, an interface for acoustic coupler 
operation, AT command set compatibility, auto-dial and -answer, auto-rate select, and 
Bell and CCITT compatibility. Cost: $699. 

An error-correcting, 2400-bps, internal modem for the Apple Macintosh II PC. Imple¬ 
ments X.PC and MNP Levels 2, 3, and 4 error-correction protocols. Also supports MNP 
Level 5. Uses error-correction dial modifiers. Also AT command set compatible. Cost: 


144 


145 


146 


Xecom 
XE2400MNP 
Component modem 


Yarc Systems 

AT-Super 

Coprocessor 


A 2400-bps component modem for microprocessor-based OEM equipment. Measures 147 

2.75 x 1.38 x .5 inches. Contains MNP protocols to Class 5. Has an internal data access 
arrangement with user-transferrable FCC Part 68 Registration. Also interfaces to external 
DA As. Cost (1,000s): $220. 

A coprocessor system fpr the IBM PC-AT or 80386-compatible. Includes an Am29000 148 

32-bit RISC CPU with separate instruction and address buses, 512 Kbytes of SRAM, and 2 
Mbytes of instruction memory. Has a 50-MHz system clock. Uses DOS. Cost: $4,595. 
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IEEE COMPUTER SOCIETY ^ 

Membership / Subscription Application 


BENEFITS 


Computer 

Computer comes automatically 
with membership. Written, 
reviewed, and refereed by 
experts, it features survey and 
tutorial articles covering the 
entire computer field, and 
departments such as new 
products, new product reviews, 
standards, and a reader forum 
called “The Open Channel.” 
(monthly). 

Technical Committees 

Participate in one or more of our 33 technical 
committees — networks of professionals with common 
interests in specialty areas within computer hardware, 
software, and applications. 

Standards Working Groups 
Participate in the development of the more than 100 
standards projects currently sponsored by the society 
in such diverse areas as software engineering, local 
area networks, microprocessor buses, design automa¬ 
tion, programming languages, and standards 
definitions. 

Computer Society Press Books 

Receive discounts of up to 50% on over 600 titles 
covering a broad spectrum of computer science topics 
such as networking, communications, advanced 
systems, image processing, security, artificial 
intelligence, and design automation. Over 60 new titles 
are published annually. 

Conferences and Tutorials 
Choose from more than 100 conferences annually, 
ranging from large industry-oriented conferences 
replete with exhibits to small, highly interactive 
workshops. Members receive special low rates. 



To join: see item 1, 2, or 3. 
Schedule of Fees To subscribe: see item 4. 

Membership dues and periodical subscriptions are annualized to, 
and expire on, December 31. Choose full or half-year rate schedules 
depending on date of receipt by the Computer Society Half Year Full Year 
as indicated below._Mar 1-Aug 31 Sept 1-Feb 28 

I I don’t belong to the IEEE and I want □ $19.50 □ $39.00 

to join just the Computer Society 

2 1 don’t belong to the IEEE and I want 

to join both the Computer Society and the IEEE* 

(Total amount to be paid includes annual dues, and regional assessment, if any.) 

I reside in Region 1-6 (United States) . □ $44.00 □$88.00 

I reside in Region 7 (Canada). □ $41.00 □ $82.00 

I reside in Region 8 (Europe, Africa, orthe Middle East) □ $41.50 □$83.00 

I reside in Region 9 (Latin America). □ $36.00 □ $72.00 

I reside in Region 10 (Asia and Pacific). □ $37.00 □ $74.00 

*ACM members who join both IEEE and the Computer Society may deduct $5 off the 
full-year rate; $2.50 off the half-year rate. 

3 1 already belong to the IEEE and I want □ $ 7.50 □ $15.00 

to join the Computer Society. 

IEEE Member Number_ 


^ OPTIONAL PERIODICALS for new 


current members 


IEEE Computer Graphics and Applications (3061) 6 


IEEE Design and Test (3111) .6 

IEEE Expert (3151) .4 

IEEE Micro (3071) .6 

IEEE Software (3121) .6 

Transactions on Computers (1161) .12 

Transactions on Knowledge and 

spn" 9 Data Engineering (1471) .4 

6 Transactions on Pattern Analysis and 

Machine Intelligence (1351) .12 

Transactions on Software Engineering (1171) .12 


□ 

$ 9.50 

□ 

$19.00 

□ 

$10.00 

□ 

$20.00 

□ 

$ 6.00 

□ 

$12.00 

□ 

$ 9.00 

□ 

$18.00 

□ 

$ 9.00 

□ 

$18.00 

□ 

$10.00 

□ 

$20.00 

□ 

$ 5.00 

□ 

$10.00 

d 

$10.00 

□ 

$20.00 

□ 

$10.00 

□ 

$20.00 


Total amount remitted with this application $ 

□ Checks are accepted in Belgian, British, German, Swiss, Japanese, or 
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CONFERENCES 


Blasgen to map out evolution to post-RISC in ISCA 89 keynote address 


Michael W. Blasgen of IBM Research 
plans to tackle the evolution to post- 
RISC architectures in his keynote 
address at the 16th Annual Interna¬ 
tional Symposium on Computer Archi¬ 
tecture, scheduled for May 28-June 1 in 
Jerusalem, Israel. 

Before Blasgen speaks, John A. Dar- 
ringer of IBM Research will fill in the 
background with an opening talk on 
trends in technology and systems. 

ISCA 89 is sponsored by the IEEE 
Computer Society’s Technical Commit¬ 
tee on Computer Architecture and the 
Association for Computing 


Machinery’s Special Interest Group on 
Architecture. Michael Yoeli and Gabriel 
Silberman of Technion will co-chair the 
event. 

J.C. Syre of ECRC will serve as pro¬ 
gram chair, assisted by vice-chairs 
Arvind of MIT (US), J. Gurd of the 
University of Manchester (Europe and 
Israel), and M. Kitsuregawa of the Uni¬ 
versity of Tokyo (Far East). D. Tabak 
of GMU will serve as the tutorials chair. 

Sunday, May 28, is reserved for 
tutorials. The following days will see a 
variety of talks and panel discussions. 
Tutorials again occupy Thursday, June 


1. For a listing of topics, see the three- 
page advertisement in this issue of 
Computer. 

Applications for travel grants will be 
accepted until April 15, with recipients 
receiving notification by April 31. 
Three categories of travel grants will be 
available: student grants, US scientists, 
and general. Grants will be awarded 
based on potential contributions to the 
symposium’s technical program and 
associated workshops, and need. 

The Eckert-Mauchly Award 
ceremony will highlight a banquet to be 
held on Tuesday, May 30. 


Economically important WSI outpaces scheduled Japan intro, says Sasaki 

Michael J. Little, Hughes Research Labs 


Tadashi Sasaki of Sharp Corp. 
presented compelling arguments for the 
economic importance of wafer scale 
integration for future complex micro¬ 
electronic systems during the Interna¬ 
tional Conference on Wafer Scale 
Integration, held in San Francisco 
January 3-5. 

Speakers and attendees at the confer¬ 
ence, sponsored jointly by the IEEE 
Computer Society and the IEEE Com¬ 
ponents, Hybrids, and Manufacturing 
Technology Society, discussed world¬ 
wide efforts in the area of WSI. The 
invited overview speakers described 
impressive wafer-scale activities in 
Japan, the United Kingdom, Europe, 
and the United States. 

Sasaki described Japan’s long-range 
plan to bring its WSI technology into 
place in the year 2000. He commented 
that progress is well ahead of schedule, 
so we should see this technology used in 
the 1990s. 

“This much is certain,” said Sasaki. 
“New process technology oriented 
toward wafer scale integration will be 
introduced gradually into chip design, 
as designers find new ways to resolve 
the [WSI] problems I have been talking 
about. Unlike conventional LSI 
designs, which require special circuit 


design expertise and knowledge of phys¬ 
ical properties, wafer scale integration 
allows designers with less knowledge 
and experience [in these areas] to come 
up with successful chip designs.” 

Michael Lea, a leading researcher in 
WSI from Brunei University in the UK, 
described the extensive activity and 
progress occurring in the UK and 
Europe. Within the UK, the 
government-sponsored Alvey program 
has focused on developing WSI during 
the last four years. This program brings 
together university and industrial 
researchers in a well-orchestrated and 
well-funded approach. 

The progress made under the Alvey 
program, in both computers and mem¬ 
ory systems, has been dramatic. 
Demonstrations of operating prelimi¬ 
nary designs have been made and more 
are imminent, according to Lea. 

Lea also highlighted the European 
Esprit program, aimed at developing 
and inserting WSI technology into com¬ 
mercial and government systems. 

Again, significant progress was evident 
from the descriptions of operating WSI 
components. 

The majority of the conference 
papers were contributed by researchers 
in the US. These papers covered all 


aspects of WSI: wafer-scale metalliza¬ 
tion technology for power, ground, and 
signal distribution; defect and yield 
modeling; redundancy strategies; circuit 
repair technology; and testing. 

An exciting development representing 
a significant maturing of WSI is the 
appearance of software tools developed 
to aid system engineers in simulating 
WSI systems. 

Earl Swartzlander of TRW Defense 
Systems Group served as general chair 
for this year’s WSI conference. Joe 
Brewer of Westinghouse Electric served 
as program chair, and Lea was Euro¬ 
pean chair. 

The conference proceedings can be 
obtained by specifying order No. 1901 
when contacting the Computer Society 
Press, 10662 Los Vaqueros Circle, Los 
Alamitos, CA 90720-2578, phone (800) 
CS-BOOKS. In California, dial (714) 
821-8380. The IEEE and Computer 
Society-member price is $40, and the 
nonmember price is $80. 

Next year’s WSI conference will be 
held January 23-25, again in San Fran¬ 
cisco. With the high interest shown in 
WSI, the conference organizers antici¬ 
pate a substantial increase in the paper 
submissions and conference attendance. 


104 


COMPUTER 








Infosec poses problems for developers, requires a holistic approach 


Dixie B. Baker, The Aerospace Corp. 

Information security (infosec) 
requires a system approach, with all 
supporting technologies considered in a 
holistic manner and interjected into the 
application framework. 

So said keynote speaker John J. 

Lane, vice president of Computer 
Sciences Corp., at the Fourth Aer¬ 
ospace Computer Security Applications 
Conference. His wide-ranging talk also 
presented information from a yet to be 
completed major infosec study commis¬ 
sioned by the National Security Agency 
and chaired by Lane. 

The conference was sponsored by the 
IEEE Computer Society in conjunction 
with the American Society for Indus¬ 
trial Security, the American Institute of 
Aeronautics and Astronautics, the 
Department of Defense Computer Insti¬ 
tute, and Aerospace Computer Security 
Associates. It took place December 
12-16 in Orlando, Florida. 

The conference grew out of the recog¬ 
nition of a need to address the conflict¬ 
ing interests facing developers of civil 
and military applications. On the one 
hand, users demand that ever-increasing 
volumes of information be quickly and 
conveniently accessible to them. At the 
same time, security policies and grow¬ 
ing public security awareness force 
developers to ensure that the systems 
serving these users protect the data 
from both malicious and unintentional 
compromises of privacy and integrity. 

Responding to these interests requires 
the application of evolving computer 
security technologies to new systems 
under development, as well as the 
implementation of technical and opera¬ 
tional solutions to enhance the security 
of existing systems. In addition, 
research and development in computer 
security technologies must respond to 
the unique needs of the application 
environments requiring protection. 

The conference committee included 
Marshall Abrams of Mitre Corp. as 
general chair; William Bisignani of 
Mitre Corp. as program chair; Doug 
Hunt of NASA and Ron GoVe of Booz- 
Allen & Hamilton as program co¬ 
chairs; and Dixie Baker as tutorial 
chair. 

The conference explored two com¬ 
plementary aspects of computer security 
technology: the policy issues and opera¬ 
tional requirements related to protect¬ 
ing civil and military systems, and the 
hardware arid software tools and tech¬ 
niques and engineering approaches 
being developed and used to satisfy sys¬ 
tem requirements. The major emphasis 


was on specific examples of system 
applications and the technical solutions 
and research-and-development efforts 
that address the computer security 
needs of these applications. 

The three-day conference was 
preceded by two days of tutorials: full- 
day sessions on secure system design, 
recent developments in distributed sys¬ 
tems security, and approaches to data¬ 
base security. In addition, two half-day 
tutorials addressed security assurance 
issues in configuration management and 
compliance with the Computer Security 
Act of 1987. 

The conference comprised three 
tracks that addressed topics of concern 
to both the public and private sectors, 
including computer viruses, database 
management system security, trusted 
systems development, integrity, net¬ 
work security, and modeling and verifi¬ 
cation. 

The conference proceedings can be 
obtained by specifying order No. 895 
when contacting the Computer Society 
Press, 10662 Los Vaqueros Circle, Los 
Alamitos, CA 90720-2578, phone (800) 
CS-BOOKS. In California, dial (714) 
821-8380. The IEEE and Computer 
Society-member price is $30, and the 
nonmember price is $60. 


Infosec study report. The infosec 
study conducted by the Air Force Com¬ 
munications and Electronics Associa¬ 
tion (AFCEA) was commissioned by 
the National Security Agency to inves¬ 
tigate the status of infosec. Although 
the study is not yet completed, Lane 
presented tentative conclusions and 
recommendations that have been dis¬ 
tributed to the study group for review. 

The specific objectives of the study 
were: to identify and define the basic 
categories of information and the chief 
factors underlying the needs for infosec 
into the twenty-first century; to identify 
the categories needing attention; and to 
determine how the government should 
convey infosec information to the user 
community. 

The study team conducted interviews 
with individuals involved in both the 
government and the private sector. Its 
preliminary conclusions were 

(1) A general lack of security aware¬ 
ness exists, particularly within the pri¬ 
vate sector. However, the study found 
widespread use of evaluated products in 
the private sector, primarily those rated 
“C2” by the National Computer Secu¬ 
rity Center using the Trusted Computer 
System Evaluation Criteria (TCSEC). 


(2) Government guidelines are viewed 
as too technical and are not well 
known. 

(3) Internationally accepted and 
approved solutions are needed. Solu¬ 
tions must be exportable. 

(4) User acceptability of computer 
security products is a function of cost 
and ease of use. Assessing the costs 
associated with a security breach is dif¬ 
ficult but necessary, particularly in the 
private sector. Usability is critical; secu¬ 
rity features cannot significantly reduce 
usability. 

(5) Users are looking for guidance, 
not regulation. 

(6) Infosec must be addressed as a 
total system problem; Tempest, com- 
pusec, etc., must be looked at 
holistically. 

(7) Current practice emphasizes dis¬ 
crete disciplines, particularly physical 
security, Tempest, and comsec. 

(8) Security responsibility resides with 
the system owner, with technical sup¬ 
port from the security staff. 

(9) “Best” versus “good enough” is 
a major problem within the private sec¬ 
tor. The “best” protection is not 
wanted if it means increased cost or 
decreased usability. 

(10) A need exists for formalization 
with regard to threat analysis and risk 
assessment, consistent with good busi¬ 
ness practice. 

(11) No accepted central infosec 
information service exists to provide a 
business focus. 

(12) Transparent infosec is a critical 
system goal. 

(13) Little consistency or standardiza¬ 
tion exists among user communities. 
Infosec is handled differently depending 
upon the user community (for example, 
the medical field handles infosec differ¬ 
ently than does the insurance industry). 
More attention is needed from an appli¬ 
cations point of view. 

The study team made a number of 
recommendations as a result of its find¬ 
ings. It noted a significant need for 
security awareness and recommended 
that professional and trade associations 
be used to convey the message, focusing 
on the corporate executive level. Specif¬ 
ically, the team suggested developing a 
handbook addressing risk, threat assess¬ 
ment, and infosec protection, and 
establishing a central source for infor¬ 
mation and applications guidance. 

The study team’s recommendations 
also included an extensive list of areas 
needing government support. It recom¬ 
mended that the government develop 
the infosec market by encouraging 
industry investment through requests 
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for proposals with “teeth,” providing 
seed money for research and develop¬ 
ment, and encouraging infosec educa¬ 
tion at all levels within user and 
academic communities. 

The study team concluded that guid¬ 
ance, not regulation, was needed. It 
recommended the establishment of an 
“underwriter’s laboratory” with seed 
funding from the government, but with 
the immediate goal of becoming self- 
sustaining within the private sector. The 
team sees infosec as a global issue 
demanding internationally acceptable 
solutions. 

Correcting flaws. Alice Baker, head 
of the Department of Energy Center for 
Computer Security, introduced a dis¬ 
cussion regarding the control and dis¬ 
semination of information concerning 
security flaws and their correction. The 
DOE is attempting to address the prob¬ 
lem of how to securely disseminate 
information about vulnerabilities. The 
current policy is that if the information 
concerns a vulnerability in a classified 
system, the information on the vulnera¬ 
bility and the fix is classified for a speci¬ 
fied period of time, then declassified. 

The DOE recognizes problems in this 
procedure and is seeking a better 
solution. 

Another concern Baker addressed 
was that some system managers are not 
able to apply the patches they receive, 
since they are accustomed to having a 
vendor install all fixes. She believes that 
the two biggest problems the DOE faces 
are ensuring the integrity of the fix itself 


According to Dave Brown, technical 
program chair, the continued success of 
the Custom Integrated Circuits Confer¬ 
ence results from the tremendous 
growth of the International application- 
specific IC industry. “The technical 
program, educational sessions, and 
exhibitors promise to make CICC '89 
an exciting conference for designers, 
manufacturers, and users of custom 
integrated circuits,” said Brown. 

CICC '89 will be held May 15-18, 
1989, at the Town & Country Hotel in 
San Diego. Sponsored by the Institute 
of Electrical and Electronics Engineers, 
the conference is expected to draw 1,400 
attendees. 

Papers presented will detail the latest 
developments in custom and semi¬ 
custom circuits, analog and digital 
design techniques, CAD methodology, 
test, reliability, fabrication technology, 


and ensuring that the fix is installed cor¬ 
rectly. 

Three solutions have been proposed 
to date. The first was identified as the 
“Locksmith mentality” approach, in 
which the fix is distributed without an 
explanation of what the problem is or 
exactly how the fix works. The second 
solution addressed the problem of the 
disinclination of vendors to disseminate 
vulnerability information about their 
systems. Vendor liability was suggested 
as a possible approach to remedy this 
problem. The third solution was setting 
up a central distribution mechanism. 

P.H. Wiedemann of SSDS Inc. then 
categorized and discussed issues relating 
to the distribution of vulnerability 
information and fixes. He noted that a 
number of interested parties were 
involved, and the approach must con¬ 
sider both protectors and potential 
exploiters, as well as the value of exploi¬ 
tation. 

Wiedemann also addressed the prob¬ 
lem of control objectives, including 
what he identified as the “chameleon 
effect” in which an insider in one 
organization is an outsider in another. 

He discussed current dissemination 
practices in both the military and civil 
sectors, noting that, generally, protec¬ 
tors are constrained by bureaucratic 
regulations, while exploiters operate 
freely and unconstrained. Nor are pro¬ 
tectors “rewarded” for reporting a 
flaw; neither victims nor system ven¬ 
dors like hearing about system vulnera¬ 
bilities that must be fixed. He also 
talked about the reporting and response 


simulation, and modeling. The techni¬ 
cal program committee has selected 178 
papers from more than 480 sub¬ 
missions. 

Three panel sessions to be conducted 
Wednesday evening will supplement the 
technical sessions. 

Monday, May 15, will feature eight 
education presentations. That evening, 
attendees can learn about new products 
in two concurrent sessions. 

James Solomon of Cadence Design 
Systems will open the conference with a 
keynote address. His talk, “Design 
Automation for Analog and Mixed 
Analog-Digital ICs,” will examine the 
needs of designers and the capability of 
the next generation of CAD equipment. 

For more information, contact con¬ 
ference coordinator Laura A.H. Mori- 
hara, Convention Coordinating, 298 
Ohina Place, Kihei, Maui, HI 96753, 
phone (808) 879-9128. 


environments and raised issues relating 
to what actions and responsibilities 
should be required, including the 
responsibilities of the discoverer, manu¬ 
facturer, security officer, system owner, 
and data owner. 

In the ensuing discussion, a member 
of the audience mentioned a recent 
news release from the Department of 
Defense announcing the establishment 
of a Defense Advanced Research 
Projects Agency (DARPA) Computer 
Emergency Response Team (CERT). 
The release, dated December 6, stated 
that the CERT had been established to 
address the computer security concerns 
of research users of the Internet, which 
includes ARPAnet. The coordination 
center for the team will be located at the 
Software Engineering Institute at Car¬ 
negie Mellon University. 

The release further stated that, in 
providing direct service to the Internet 
community, the CERT will focus on the 
needs of the research community and 
will serve as a prototype for similar 
operations in other computer communi¬ 
ties. The National Computer Security 
Center and the National Institute of 
Standards and Technology will have 
leading roles in coordinating the crea¬ 
tion of emergency response activities. 

Trusted Mach. H. Tajalli, F. Mayer, 
and W. Barker of Trusted Information 
Systems presented three papers regard¬ 
ing a prototype trusted operating sys¬ 
tem, targeted at class B3, which they are 
developing under the sponsorship of 
DARPA. 

Tajalli described the Trusted Mach 
(TMach) prototype, which is a Unix- 
compatible system based upon the 
Mach kernel under development at Car¬ 
negie Mellon University. The system 
currently includes Berkeley 4.3 Unix, 
which eventually will be replaced with a 
Unix emulation. The prototype is 
scheduled for completion by mid-1989. 

TMach is a message-passing, server- 
oriented system comprising two layers: 
a kernel layer and a server layer. 

The kernel supports the following 
basic abstractions: ports, which are 
similar to message queues; tasks, the 
execution environments, which are the 
subjects; threads, which are active units 
of execution within tasks; messages, 
which are data objects used for commu¬ 
nication between threads; and paging 
objects, which represent secondary 
storage. 

Tasks can communicate only by send¬ 
ing a message, by issuing a Kernel Inter¬ 
face command, or via shared memory 
between parent and child tasks. Each 
port belongs to a single task, which has 
“receive” rights to the port. Multiple 
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tasks can have “send” rights to a port. 
All kernel objects are represented by 
ports. The “send” and “receive” con¬ 
stitute two separate operations. In the 
TMach prototype, ports and tasks are 
labeled, with the kernel providing 
access mediation primarily by control¬ 
ling the transfer of port access rights. 

Most operating system functions are 
implemented at the server layer by 
trusted servers, which include a name 
server, a file server, an audit server, and 
a verification server. The name server 
performs both mandatory and discre¬ 
tionary access control on all non-kernel 
objects. 

Consistent with the B3 requirement 
for a formal security model, TMach is 
based upon an interpretation of a 
refined Bell-LaPadula model. Mayer 
discussed the variants introduced for 
modeling the TMach kernel. TMach’s 
unique architecture required recognition 
of a range of security levels within 
which a subject is trusted, rather than 
the “all or nothing” allowance for 
trusted subjects in the original model. 

An interpretation of the Bell-LaPadula 
model for networks was used as the 
basis for the formal model. Unlike the 
conventional approach, where a single 
security model is developed for the 
entire system, TIS is developing 
“layers” of security models that cor¬ 
respond to the TMach architectural 
layers. 

Finally, W. Barker discussed research 
regarding embedding cryptography into 
a trusted system. Specifically, an 
embedded secure network prototype is 
being developed using the TMach oper¬ 
ating system. Secure Data Network Sys¬ 
tems (SDNS) protocols are being 
implemented at the application and 
transport layers. Currently, TIS is 
working on the application layer, with 
the transport layer scheduled for next 
year. The prototype is being developed 
using unclassified cryptography, specifi¬ 
cally RSA for authentication and key 
protection and DES for privacy and 
integrity encryption. Future plans 
include implementation of CCEP cryp¬ 
tographic capabilities. 

Trusted system development panels. 

A number of panels addressed various 
issues relating to trusted system devel¬ 
opment. Both current and future activi¬ 
ties relating to the development of 
operating systems, networks, and data¬ 
base management systems were dis¬ 
cussed. Panelists included product 
developers, researchers, and users from 
industry and the government. 

One system development panel 
focused on the compartmented mode 
workstations (CMWs) being developed 


for the Defense Intelligence Agency 
(DIA) by five vendors (IBM, Harris, 
Secureware, Digital Equipment, and 
Sun), three of whom were represented 
on the panel (Secureware, Harris, and 
Digital), along with the National Com¬ 
puter Security Center Program Man¬ 
ager for CMW evaluation. 

The panel explored a number of 
problems and opportunities relating to 
the development of the CMWs and 
similar secure products. Some of the 
basic questions addressed were: What 
are the user requirements for multilevel 
workstations? Who are the users? Why 
are the DIA CMW requirements as they 
are? 

In addressing the applicability of and 
customer base for the CMWs versus 
workstations rated “B2” according to 
the TCSEC, the panel focused primarily 
on differences in requirements and the 
inconsistencies and interplay between 
the TCSEC’s “Bl” requirements and 
the CMW. 

Another panel discussed issues relat¬ 
ing to database management system 
security. Adding security to DBMSs has 
opened a number of unsolved issues 
relating to the internal workings of the 
DBMS and at the interface between the 
DBMS and the trusted computing base 
(TCB). The stated intent of this panel 
was to raise a number of these issues, 


currently being debated in the research 
community, whose resolution will 
strongly impact the commercial secure 
database systems being developed. 

One of the major technical issues dis¬ 
cussed was that of “balanced assur¬ 
ance,” which is the idea that one can 
build an “Al” TCB by putting together 
a security kernel that enforces the man¬ 
datory policy with Al assurance and 
provides C2 features for discretionary 
access control and audit, plus a trusted 
path for security relevant events. 

1989 conference planned. The Fifth 
Aerospace Computer Security Applica¬ 
tions Conference is scheduled for 
December 4-8, 1989, in Tucson, Ari¬ 
zona. Technical papers and tutorials 
addressing the application of computer 
security technologies are solicited. 
Original research, analyses, and poten¬ 
tial or implemented solutions to com¬ 
puter security problems are of 
particular interest. Persons interested in 
submitting papers may contact Ronald 
A. Gove, Technical Program Chair, 
Booz-Allen & Hamilton, 4330 East- 
West Highway, Bethesda, MD 20814. 
Persons interested in submitting tutorial 
proposals may contact Dixie B. Baker, 
Tutorial Program Chair, The Aer¬ 
ospace Corp., PO Box 92957, Los 
Angeles, CA 90009. 


CompEuro targets VLSI and computer peripherals 


CompEuro '89, the International 
Conference on VLSI and computer 
peripherals, will take place in Hamburg 
on May 8-12, 1989. It will be held at the 
Congress Center Hamburg. 

The conference covers advanced tech¬ 
nologies and trends in VLSI and exter¬ 
nal memories; VLSI and I/O systems 
and devices for human interface; VLSI, 
sensors, and controls; VLSI and com¬ 
puter communications, and VLSI for 
peripherals. 

Conference organizers anticipate 
400-500 attendees. Walter E. Proebster 
of IBM Laboratory and Winfried 
Schott of Alldephi are conference 
chairs, while Hans Reiner of SEL serves 
as technical program chair. Wilhelm 
Anacker of GMD and Roland Beyer of 
IBM Laboratory are chairs for the 
tutorial program. 

The plenary session will be held the 
morning of Wednesday, May 10. Ple¬ 
nary session topics and speakers include 
“The Future of Optical Recording” by 
G.E. Thomas of Philips Research, 
“Japanese I/O Technology; Where it is 
and how it got there” by Robert A. 
Myers of IBM Japan, “Technological 


Changes in the Field of Sensors” by C. 
Weyrich of Siemens, “Broadband 
Communication — Key to Advanced 
Terminals” by H. Ohnsorge of 
SEL/Alcatel, “VLSI — The Driving 
Force for Computer Peripherals” by 
W. Liebmann of Burlington University, 
and “Beyond Icons — Surface and 
Structures of User Interfaces” by J. 
Nievergelt, University of North 
Carolina. 

The conference is sponsored by the 
IEEE Computer Society, IEEE Region 
8, VDE (Verband Deutscher Elek- 
trotechniker), and GI (Gesellschaft fiir 
Informatik). It is organized in coopera¬ 
tion with Eurel, Euromicro, GME, 

ITG, SI, the Society for Information 
Display, the European Physical Society, 
the IEEE Electron Device Society, the 
IEEE Lasers and Electro-Optics Soci¬ 
ety, and the IEEE Communication 
Society. 

Contact W.E. Proebster, IBM 
Laboratory, Dept. 3280, 7030-14, 
D-7030 Boblingen, FRG, phone (0049) 
7031-163929, for final programs, regis¬ 
tration forms, requests for exhibition 
space, and further information. 
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CALL FOR PAPERS 


Call for papers and referees for Computer 


Computer seeks articles for inclusion in 
the December 1989 issue on Image Data¬ 
base Management. 

This special issue will focus on recent 
research results and high-quality current- 
technology reviews. Suggested topics 
include: 

• data modeling techniques for iconic 
entities 

• design of model-base managers 

• image interpretation in an object- 
oriented environment 

• query language design for iconic 
entities 

• efficient image data representation. 


storage, and retrieval techniques 

• application-oriented image database 
management systems 

• query processing techniques that uti¬ 
lize iconic information 

Papers must not have been previously 
published or currently submitted for pub¬ 
lication elsewhere. 

A 300-word abstract of the manuscript 
should be submitted as soon as possible. 
Eight copies of the full manuscript 
should be submitted by May 1, 1989, to 
William I. Grosky, Computer Science 
Department, Wayne State University, 
Detroit, MI 48202, phone (313) 577-0722 


or 2477, e-mail to grosky@cs.wayne.edu; 
or to Rajiv Mehrotra, Department of 
Computer Science and Engineering, Uni¬ 
versity of South Florida, Tampa, FL 
33620, phone (813) 974-4761 or 4104, e- 
mail to rajiv@usf.edu 

Authors will be notified of acceptance by 
July 1, 1989. The final version of the 
manuscript is due by August 1, 1989. 

If you are interested in serving as a refe¬ 
ree, send a note with a list of your techni¬ 
cal interests to Rajiv Mehrotra or to 
Bruce Shriver, Computer editor-in-chief, 
at shriver@uhccux.uhcc.hawaii.edu 


IEEE Micro seeks articles for general- 
vS7 interest issues in 1989 and 1990. Sug¬ 
gested topics include neural networks, artifi¬ 
cial intelligence, special-purpose computers, 
optical computers and interfaces, worksta¬ 
tions, use of microprocessors in parallel 
computers, VHDL design, silicon compila¬ 
tion, and biological computing. Tutorials are 
welcome on all micro-related topics. Submit 
manuscripts to Joe Hootman, Editor-in- 
Chief, EE Dept., Univ. of North Dakota, 

PO Box 7165, Grand Forks, ND 58202, 
phone (701) 777-4331. 


First Hi-Tech Service and Maintenance 
Conf.: Oct. 31-Nov. 2, 1989, Chicago. Sub¬ 
mit abstract to Donald F. Blumberg, 1260 
Virginia Dr., Suite 200, Fort Washington, 
PA 19034, phone (215) 643-9060. 


Third Int’l Workshop on Distributed 
Algorithms: Sept. 26-28, 1989, Nice, France. 
Submit paper by Apr. 25, 1989, to Jean- 
Claude Bermond, LRI, Bat 490, Universite 
Paris-Sud, 91405 Orsay, France; or Michel 
Raynal, IRISA, Campus de Beaulieu, 35042 
Rennes, France. 


ISCIS 4, Fourth Int’l Symp. on Computer 
and Information Sciences: Oct. 30-Nov. 1, 
1989, Cesme, Turkey. Submit paper by Apr. 
25, 1989, to Asuman Dogac, Computer 
Engineering Dept., Middle East Technical 
Univ., 06531 Ankara, Turkey. 

£1^ ICCAD 89, IEEE Int’l Conf. on 
Computer-Aided Design: Nov. 6-9, 
1989, Santa Clara, Calif. Cosponsor: IEEE 
Circuits and Systems Society. Submit paper 
by Apr. 28, 1989, to ICCAD 89 Secretary, 
IEEE Computer Society, 1730 Massachusetts 
Ave. NW, Washington, DC 20036-1903, 
phone (202)371-1013. 
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Int 7 J. Computer Aided VLSI Design plans 
a special issue on design simulation and 
implementation. Publisher: Ablex Publishing 
Corp. Submit paper by Apr. 30, 1989, to 
Harry W. Tyrer, Electrical and Computer 
Engineering Dept., University of Missouri at 
Columbia, Columbia, MO 65211, phone 
(314) 882-6489. 

Second Int’l Workshop on Software 
NS? Configuration Management: Oct. 

24-27, 1989, Princeton, NJ. Cosponsors: 
ACM, Gesellschaft fur Informatik. Submit 
paper by Apr. 30, 1989, to Walter Tichy, 
Univ. of Karlsruhe, PO Box 6980, D-7500 
Karlsruhe 1, FRG, phone 49 (721) 608-3934 
(in Africa, Asia, and Australia); or Peter 
Feiler, Software Engineering Inst., Carnegie 
Mellon Univ., Pittsburgh, PA 15213 (in 
North and South America), phone (412) 
268-7790. 


® First Int’l Conf. on Deductive and 
Object-Oriented Databases: Dec. 4-6, 
1989, Kyoto, Japan. Cosponsors: Informa¬ 
tion Processing Society of Japan et al. Sub¬ 
mit paper by May 1, 1989, to Won Kim, 
MCC, 3500 W. Balcones Center Dr., Austin, 
TX 78759, phone (512) 343-0860; Jean-Marie 
Nicholas, ECRC Arabellastr. 17, 8000 
Munich 81, FRG, phone 49 (89) 926-99-110; 
or Shojiro Nishio, Information and Com¬ 
puter Sciences Dept., Faculty of Engineering 
Science, Osaka Univ., Toyonaka, Osaka, 

560 Japan, phone 81 (6) 853-5737. 


® Int’l Conf. on CAD/CAM and AMT: 

Dec. 5-7, 1989, Jerusalem, Israel. Sub¬ 
mit abstract by May 1, 1989, to IC AMI, c/o 
Ortra, POB 50432, 61500 Tel Aviv, Israel, 
phone 972 (3) 664-825. 


ji Supercomputing 89: Nov. 13-17, 1989, 
" Reno, Nev. Cosponsor: ACM. Submit 


paper by May 1, 1989, to Gary Johnson, 
North Carolina Supercomputer Center, PO 
Box 12732, Research Triangle Park, NC 
27709, phone (919) 248-1825. 


10<h Real-Time Systems Symp.: Dec. 
5-7, 1989, Los Angeles. Submit paper 
by May 1, 1989, to Douglass Locke, IBM 
Systems Integration Div., MD0212, Bodle 
Hill Rd., Oswego, NY, 13827, phone (607) 
751-4291. 


OTM Third Int’l Workshop on Petri Nets 
^ and Performance Models: Dec. 11-13, 
1989, Kyoto, Japan. Cosponsors: Society of 
Instrument and Control Engineers et al. Sub¬ 
mit paper by May 1, 1989, to Shojiro Nishio, 
Information and Computer Sciences Dept., 
Faculty of Engineering Science, Osaka 
Univ., Toyonaka, Osaka, 560 Japan, phone 
81 (6) 853-5737. 


Fourth Knowledge Acquisition for 
Knowledge-Based Systems Workshop: Oct. 
1-6, 1989, Banff, Canada. Sponsor: Ameri¬ 
can Assoc, for Artificial Intelligence. Submit 
draft paper by May 1, 1989, John H. Boose, 
Advanced Technology Center, Boeing Com¬ 
puter Services, 7L-64, PO Box 24346, Seat¬ 
tle, WA 98124, phone (206) 865-3253. 


J. Microcomputer Applications: January 
1990. A special issue is planned on trans¬ 
puter applications. Submit paper by May 1, 
1989, to F.J. Rammig, Paderborn Univ., FB 
17, Warburger Str. 100, 4790 Paderborn, 
West Germany, phone 49 (05251) 60-20-69. 

Semiconductor Manufacturing Conf.: Nov. 
14-15, 1989, Phoenix. Sponsor: Society of 
Manufacturing Engineers. Submit paper by 
May 1, 1989, to Karen L. Kammerer, Tech¬ 
nical Committee Projects Dept., SME, 1 
SME Dr., PO Box 930, Dearborn, MI 48121, 
phone (313) 271-1500. 
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Int’l Conf. on Expert Planning Systems: 

June 27-29, 1989, Brighton, England. Spon¬ 
sor: Institution of Electrical Engineers. Sub¬ 
mit paper by May 5, 1989, to Conf. Services, 
IEE, Savoy PI., London WC2R OBL, UK, 
phone 44 (1) 240-1871, ext. 222. 

£1^ IEEE Software: March, 1990. A spe- 
X*/ cial issue is planned on software devel¬ 
opment metrics. Submit paper by May 15, 
1989, to Peter Dyson, Software Productivity 
Solutions, 122 N. Fourth Ave., Indialantic, 
FL 32903, phone (407) 984-3370. 

14th Conf. on Local Computer Net- 
works: Oct. 10-12, 1989, Minneapolis. 
Submit paper by May 15,1989, to Larry 
Green, Protocol Engines, 1421 State St., 
Santa Barbara, CA 93101, phone (805) 
965-0825. 

£3^ Fifth Aerospace Computer Security 
^7 Applications Conf.: Dec. 4-8, 1989, 
Tucson, Ariz. Submit paper by May 19, 

1989, to Ronald A. Gove, Booz-AUen and 
Hamilton, 4330 East-West Hwy., Bethesda, 
MD 20814, phone (301) 951-2395. Submit 
tutorial proposal to Dixie B. Baker, The Aer¬ 
ospace Corp., PO Box 92957, Los Angeles, 
CA. 

® Compcon Spring 90: Feb. 26-Mar. 2, 
1990, San Francisco. Submit paper by 
June 1, 1989, to Kenichi Miura, Computa¬ 
tional Research Dept., MS B2-7, Fujitsu 
America, 3055 Orchard Dr., San Jose, CA 
95134-2017, phone (408) 432-1300, ext. 5408 
or 5723. 

£3^ Sixth Int’l Conf. on Data Engineering: 

NS? Feb. 5-9, 1990, Los Angeles. Submit 
paper by June 15, 1989, to Ming T. Liu, 
Computer and Information Science Dept., 
Ohio State Univ., 2036 Neil Ave., 

Columbus, OH 43210-1277, phone (614) 
292-1837. 

£3^ IEEE Int’l Workshop on Tools for 
XS7 Artificial Intelligence: Oct. 23-25, 

1989, Fairfax, Va. Submit paper or summary 
by June 15, 1989, to Nikolas G. Bourbakis, 
Electrical and Computer Engineering Dept., 
Machine Vision Research Lab, George 
Mason Univ., 4400 University Dr., Fairfax, 
VA 22030, phone (703) 425-3930. 

£3^ Fourth Int’l Workshop on High-Level 

H? Synthesis: Oct. 15-18, 1989, Ken- 
nebunkport, Maine. Cosponsor: ACM. Sub¬ 
mit extended abstract by June 16, 1989, to 
Raul Camposano, IBM Research Div., T.J. 
Watson Research Center, PO Box 218, 
Yorktown Heights, NY 10598, phone (914) 
945-3971. 

£3^ First Int’l Conf. on Systems Integra¬ 
ls? tion: Apr. 23-26, 1990, Morristown, 
N.J. Cosponsors: New Jersey Inst, of Tech¬ 
nology et al. Submit paper by July 25, 1989, 
to Peter A. Ng, Computer and Information 
Science Dept., New Jersey Inst, of Technol¬ 
ogy, Newark, NJ 07102. 
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£3^ Conferences that the IEEE Computer Society sponsors or participates in are indi- 
^7 cated by the Computer Society logo; additional conference sponsors are also 
listed. Other conferences of interest to our readers are included, as well. 

For inclusion in Call for Papers or Calendar, submit information six weeks before 
the month of publication (i.e., for the June 1989 issue, send information for receipt by 
April 15,1988) to Chuck Governale, Calendar Dept., Computer , 10662 Los Vaqueros 
Circle, Los Alamitos, CA 90720. 


April 1989 

£3^ IEEE Design for Testability Work- 
NS7 shop, Apr. 18-21, Vail, Colo. Sponsor: 
Computer Society Test Technology Techni¬ 
cal Committee. Contact T. W. Williams, 
IBM, PO Box 1900, Dept. 67A/021, Boul¬ 
der, Co 80301-9191, phone (303) 924-7692. 

£3^ Infocom 89, Conf. on Computer Com- 
munications, Apr. 23-27, Ottawa, 
Canada. Contact Celia Desmond, Telecom 
Canada, 438 Bay St., FL5S (C5), South 
Tower, Toronto, Ont., Canada, M5G 2E1, 
phone (416) 581-2318. 

Vision 89, Apr. 25-27, Chicago. Sponsor: 
Society of Manufacturing Engineers. Con¬ 
tact Maria Nowakowski, SME, 1 SME Dr., 
PO Box 930, Dearborn, MI 48121, phone 
(313) 271-1500, ext. 376. 

Third Workshop on Empirical Studies of 
Programmers, Apr. 29-30, Austin, Tex. 
Sponsor: Foundation for the Empirical 
Studies of Programmers. Contact Gary 
Olson, Cognitive Science and Machine Intel¬ 
ligence Lab, Univ. of Michigan, Ann Arbor, 
MI 48109-1234, phone (313) 747-4948; or 
Elliot Soloway, Univ. of Michigan, EECS 
Dept., 1101 Beal Ave., Ann Arbor, MI 
48109, phone (313) 936-1562. 

39th IEEE Vehicular Technology Conf., 
Apr. 29-May 2, San Francisco. Contact 
Frank Thatcher, 564 Market St., Suite 612, 
San Francisco, CA 94104, phone (415) 
956-6118. 

Physical Design Workshop, Apr. 30-May 3, 

Long Beach, Calif. Sponsors: IEEE, ACM. 
Contact Jamie Kirkendall, ACM, 11 W. 
42nd St., New York, NY 10036, phone (212) 
869-7440; or Bryan Preas, Xerox PARC, 
3333 Coyote Hill Rd„ Palo Alto, CA 94304, 
phone (415) 494-4845. 

£3^ CHI 89, Conf. on Human Factors in 
V57 Computing Systems, Apr. 30-May 4, 

Austin, Tex. Cosponsors: ACM, Human 
Factors Society. Contact Claudia Raun or 
Bill Curtis, MCC, PO Box 200195, Austin, 
TX 78720, phone (512) 338-3798. 

34th Int’l Instrumentation Symp., Apr. 
30-May 4, Orlando, Fla. Sponsor: Instru¬ 
ment Society of America. Contact Frederick 
A. Kern, PO Box 65, Seaford, VA 23696, 
phone (804) 865-3269, 


May 1989 

1989 IEEE Symp. on Research in Secu- 
vs7 rity and Privacy, May 1-3, Oakland, 
Calif. Contact Terry V. Benzel, Trusted 
Information Systems, 11340 Olympic Blvd., 
Suite 265, Los Angeles, CA 90064, phone 
(213) 477-5828. 

1989 SME Int’l Conf., May 1-4, Detroit. 
Sponsor: Society of Manufacturing 
Engineers. Contact SME, PO Box 930, Dear¬ 
born, MI 48121, phone (313) 271-1500. 

Third AI Research in Environmental Science 
Workshop, May 2-4, Washington, DC. Con¬ 
tact William R. Moninger, Environmental 
Research Labs, NOAA, R/E2, 325 Broad¬ 
way, Boulder, CO 80803, phone (303) 
497-6435. 

Sixth Canadian Symp. on Instructional 
Technology, May 3-5, Halifax, N.S., 

Canada. Sponsor: National Research Coun¬ 
cil Canada. Contact Laurier Forget, CSIT, 
Conf. Services, NRCC, Ottawa, Ont. K!A 
OR6, Canada, phone (613) 993-9009. 

20th Pittsburgh Conf. on Modeling and 
Simulation, May 4-5, Pittsburgh, Pa. Spon¬ 
sor: Univ. of Pittsburgh. Contact William G. 
Vogt or Marlin H. Mickle, 348 Benedum 
Engineering Hall, Univ. of Pittsburgh, Pitts¬ 
burgh, PA 15261. 

Robots 13, May 7-11, Gaithersburg, Md. 
Sponsor: Society of Manufacturing 
Engineers. Contact Rebecca Alsup, SME, 1 
SME Dr., Dearborn, MI 48121, phone (313) 
271-1500, ext. 358. 

STA 5, Fifth Structured Techniques Assoc. 
Conf., May 8-11, Chicago. Sponsors: STA, 
ACM. Contact STA, c/o Robert Binder Sys¬ 
tems Consulting, Inc., 3 First National 
Plaza, Suite 1400, Chicago, IL 60602. 

34th Int’l SAMPE Symp., May 8-11, Reno, 
Nev. Sponsor: Society for the Advancement 
of Material and Process Engineering. Con¬ 
tact Marge Smith, SAMPE, PO Box 2459, 
843 W. Glentana, Covina, CA 91722, phone 
(818)331-0616. 

CompEuro 89, Int’l Conf. on VLSI 
X57 and Computer Peripherals, May 8-12, 

Hamburg. Cosponsors: Gesellschaft fur 
Informatik et al. Contact Walter E. Proeb- 
ster, IBM Lab, PO Box 1380, D-7030 Boeb- 
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lingen, Schonaicher Str. 220, Federal 
Republic of Germany, phone 49 (70) 
3116-3929. 

ICCAL 89, Second Int’l Conf. on 
Computer-Assisted Learning, May 9-11, 

Dallas. Sponsor: Computer Learning 
Research Center, Univ. of Texas at Dallas. 
Contact Janet Harris, Center for Continuing 
Education, Univ. of Texas at Dallas, PO 
Box 830688, MS CN 1.1, Richardson, TX 
75083-0688. 


CCC 89, Second Hungarian Custom Circuit 
Conf., May 10-12, Szeged, Hungary. 
Cosponsors: Scientific Society of Measure¬ 
ment and Automation (MATE). Contact 
MATE Secretariat, 1055 Budapest, Kossuth 
L. ter 6-8, Hungary, phone (1) 531-406. 


^ Sixth IEEE Workshop on Real-Time 
Operating Systems and Software, May 
11-12, Pittsburgh. Cosponsor: Carnegie Mel¬ 
lon Univ. Contact Andre van Tilborg, Office 
of Naval Research, 800 N. Quincy St., 
Arlington, VA 22217-5000, phone (202) 
696-4302. 


AAMSI Congress 89, May 11-13, San Fran¬ 
cisco. Sponsor: American Assoc, for Medi¬ 
cal Systems and Informatics. Contact 
AAMSI, Suite 700, 1101 Connecticut Ave. 
NW, Washington, DC 20036, phone (202) 
857-1189. 


First Int’l Workshop on Human and 
Machine Cognition, May 11-13, Santa Rosa 
Island, Fla. Contact Ken Ford, Computer 
Science Div., Univ. of West Florida, Pensa¬ 
cola, FL 32514, phone (904) 474-2551. 


SID 89, Society for Information Display 
Int’l Symp., Seminar, and Exhibition, May 
15-19, Baltimore. Contact Society for Infor¬ 
mation Display, c/o Palisades Inst, for 
Research Services, 201 Varick St., Rm. 1140, 
New York, NY 10014, phone (212) 620-3375. 


® Int’l Symp. on VLSI Technology, Sys¬ 
tems, and Applications, May 17-19, 

Taipei, Taiwan. Cosponsors: Republic of 
China National Science Council, Industrial 
Technology Research Inst. Contact Alice M. 
Chiang, MIT, Lincoln Lab, Lexington, MA 
02173-0073, phone (617) 981-4629. 


Chapel Hill Workshop on Volume Visualiza¬ 
tion, May 18-19, Chapel Hill, N.C. Sponsor: 
Univ. of North Carolina, Molecular 
Graphics Society. Contact Frederick P. 
Brooks, Jr., Computer Science Dept., Univ. 
of North Carolina, Chapel Hill, NC 
27599-3175 


glv Fifth Int’l Workshop on Software 
^ Specification and Design, May 19-20, 

Pittsburgh. Cosponsor: ACM. Contact Sol 
J. Greenspan, GTE Labs, 40 Sylvan Rd„ 
Waltham, MA 02254, phone (617) 466-2962; 
or Colin Potts, MCC, 9390 Research Blvd., 
Kaleido II Bldg., Austin, TX 78759, phone 
(512) 338-3629. 


ICCI 89, Int’l Conf. on Computing and 
Information, May 23-27, Toronto. Contact 
Waldemar W. Koczkodaj, Laurentian Univ., 
CoSc, Sudbury, Ont., Canada P3E 2C6, 
phone (705) 675-1151. 


Workshop on New Directions in Computer 
Chess, May 28-June 1, Edmonton, Alta., 
Canada. Sponsors: Int’l Computer Chess 
Assoc., Canadian Information Processing 
Society. Contact Tony Marsland, Comput¬ 
ing Science Dept., Univ. of Alberta, Edmon¬ 
ton, Alta., Canada T6G 2H1. 


XS7 tecture, May 28-June 1, Jerusalem, 
Israel. Cosponsor: ACM. Contact M. Yoeli, 
Computer Science Dept., Technion City, 
Haifa 32000, Israel, phone 972 (4) 294-314. 

® 19th Int’l Symp. on Multiple-Valued 
Logic, May 29-31, Guangzhou, China. 
Cosponsors: Chongging Univ. et al. Contact 
David M. Miller, Computer Science Dept., 
Univ. of Victoria, B.C., Canada, V8W 2Y2, 
phone (604) 721-7220. 


CIPS National Congress 89, May 29-June 2, 

Edmonton, Alta., Canada. Sponsor: CIPS. 
Contact Congress 89, PO Box 1277, Main 
Post Office, Edmonton, Alta., Canada T5J 
2M8, phone (403) 488-1879 


VfV First IEEE Symp. on Parallel and Dis- 
'3/ tributed Processing, May 22-23, 

Dallas. Sponsor: Dallas Section of the 1F.RF 
Computer Society. Contact Mark Shado- 
wens, Information Technologies Lab, Texas 
Instruments, PO Box 655474, MS 238, 
Dallas, TX 75265, or call Behrooz Shirazi at 
(214) 692-2874. 


nS 7 31-June 2, Killarney, Ireland. Cospon¬ 
sor: Queen’s Univ. of Belfast. Contact Earl 
Swartzlander, TRW, 1 Space Park, Redondo 
Beach, CA 90278, phone (213) 535-4321. 


First Int’l Symp. on Integrated Network 
Management, May 14-17, Boston. Sponsor: 
IFIP. Contact Hershey Young, Nat’l Inst, of 
Standards and Technology, Building 225, 
Rm. B217, Gaithersburg, MD 20899, phone 
(301) 975-5267. 


Int’l Conf. on Robotics and Automation, 
May 14-19, Scottsdale, Ariz. Sponsor: IEEE. 
Contact Harry Hayman, PO Box 3216, Sil¬ 
ver Spring, MD 20901, phone (301) 434-1990 
or (407) 483-3037. 


1111* Int’l Conf. on Software Engineer- 
ing, May 15-18, Pittsburgh. Cospon¬ 
sor: ACM. Contact Larry Druffel, Software 
Engineering Inst., Carnegie Mellon Univ., 
Pittsburgh, PA 15233, phone (412) 268-7740; 
or IEEE Computer Society, 1730 Mas¬ 
sachusetts Ave. NW, Washington, DC 
20036-1903, phone (202) 371-1013. 


Sixth Conf. on Real-Time Applications in 
Nuclear, Particle, and Plasma Physics, May 
15-18, Williamsburg, Va. Sponsors: IEEE et 
al. Contact Roy Whitney, 12000 Jefferson 
Ave., Newport News, VA 23606, phone 
(804) 249-7536. 


18th Mumps Users Group Annual Meeting, 
May 15-19, Seattle. Contact Mumps Users 
Group, 4321 Hartwick Rd., Suite 510, Col¬ 
lege Park, MD 20740, phone (301) 779-6555. 


AMAST, Int’l Conf. on Algebraic Method¬ 
ology and Software Technology, May 22-24, 

Iowa City, Iowa. Contact Eugene Madison 
or Teodor Rus, Computer Science and 
Mathematics Dept., Univ. of Iowa, Iowa 
City, IA 52242, phone (319) 335-0742 or 
0694. 

Sixth Int’l Conf. on Testing Computer Soft¬ 
ware, May 22-25, Washington, DC. Spon¬ 
sors: DPMA, ACM. Contact Genevieve 
Houston-Ludlam, Frontier Technologies, 
2444 Solomons Island Rd., Suite 205, 
Annapolis, MD 21401, phone (301) 

266-8244. 

10th Tunisian French Seminar of Com- 
puter Science: The Role of Languages 
in Programming, May 23-25, Tunis, Tunisia. 
Cosponsor: Tunisian Information Processing 
Society. Contact Abdelfettah Belghith, Dept. 
d’Informatique, Faculte des Sciences de 
Tunis, 1002 Belvedere Tunisa; or Ali Mili, 
Faculty of Sciences, Univ. of Tunis II, 
Campus Universitaire, 1002 Belvedere, 
Tunisia. 

SIGMetrics 89 and Performance 89, May 
23-26, Berkeley, Calif. Sponsors: ACM, 

IFIP. Contact Luis-Felipe Cabrera, IBM 
Almaden Research Center, Mail Code 
K52/803, San Jose, CA 95120-6099, phone 
(408)927-1838. 


June 1989 

IEEE Pacific Rim Conf. on Communica¬ 
tions, Computers, and Signal Processing, 
June 1-2, Victoria, B.C., Canada. Sponsor: 
IEEE Victoria Section, Univ. of Victoria. 
Contact Warren D. Little, Dept, of Electrical 
and Computer Engineering, Univ. of Victo¬ 
ria, PO Box 1700, Victoria, B.C., Canada 
V8W 2Y2, phone (604) 721-8686. 

ICGA 89, Third Int’l Conf. on Genetic 
Algorithms, June 4-7, Washington, DC. 
Contact J. David Schaffer, Philips Labs, 345 
Scarborough Rd., Briarcliff Manor, NY. 

CVPR 89, Conf. on Computer Vision 
^ and Pattern Recognition, June 4-8, 

San Diego, Calif. Contact Rama Chellappa, 
PHE324, Electrical Engineering-Systems 
Dept., Univ. of Southern California, Univer¬ 
sity Park, MC-0272, CA 90089, phone (213) 
743-8559. 

^ Fourth Israel Conf. on Computer Sys- 
N57 terns and Software Engineering, June 
5-6, Tel Aviv. Cosponsors: Israel Chapter of 
IEEE Computer Society, Information Pro¬ 
cessing Assoc, of Israel. Contact S. Koenig, 
Ortra Ltd., PO Box 50432, Tel Aviv 61500, 
Israel, phone 972 (3) 664-825. 
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^ Fourth Symp. on Logic in Computer 
Science, June 5-8, Pacific Grove, 

Calif. Cosponsor: ACM. Contact Albert 
Meyer, Computer Science Lab, MIT, 545 
Technology Square, Cambridge, MA 02139. 

Ninth Int’l Conf. on Distributed Com- 
puling Systems, June 5-9, Newport 
Beach, Calif. Contact Kane Kim, Computer 
Engineering Program, Electrical Engineering 
Dept., Univ. of California at Irvine, Irvine, 
CA 92717, phone (714) 856-5542. 

£3^ Working Conf. on Computer-Aided 
vs7 Design Systems Using Artificial Intelli¬ 
gence Techniques, June 6-7, Tokyo. Cospon¬ 
sors: IFIP, IPSJ. Contact Akihiko Yamada, 
NEC, 4-14-22 Shibaura, Minato-ku, Tokyo 
108, Japan; or Kozo Kinoshita, Faculty of 
Integrated Arts and Sciences, Hiroshima 
Univ., 1-1-89 Sendamachi, Naka-ku, 
Hiroshima 730, Japan, phone 81 (82) 
249-9150. 

Third Int’l Workshop on Wafer Scale Inte¬ 
gration, June 6-8, Como, Italy. Sponsor: 
IFIP. Contact Mariagiovanna Sami, Dip. di 
Elettronica, Politecnico di Milano, Piazza 
Leonardo da Vinci 32,1-20133 Milan, Italy, 
phone 39 (2) 23-99-35-16. 

£3^ Second Int’l Conf. on Industrial and 
H/ Engineering Applications of Artificial 
Intelligence and Expert Systems, June 6-9, 

Tullahoma, Tenn. Cosponsors: ACM, Univ. 
of Tennessee Space Inst. Contact Moonis 
Ali, Univ. of Tennessee Space Inst., Tulla¬ 
homa, TN 37388, phone (615) 455-0631. 

Ninth Int’l Symp. on Protocol Specification, 
Testing, and Verification, June 6-9, 

Enschede, The Netherlands. Sponsor: IFIP. 
Contact ICSC, Univ. of Twente, PO Box 
217, 7500 AE Enschede, The Netherlands. 

Eighth Biennial University/Government/ 
Industry Microelectronics Symp., June 
12-14, Westborough, Mass. Sponsors: Int’l 
Society for Hybrid Microelectronics, IEEE. 
Contact Richard B. Gold, Massachusetts 
Microelectronics Center, 75 North Dr., 
Westborough, MA 01581. 

Workshop on Automatic Verification 
Methods for Finite State Systems, June 
12-14, Grenoble, France. Sponsor: C-cube, 
the French National Project on Parallelism. 
Contact Edmund M. Clarke, Jr., Carnegie 
Mellon Univ., Computer Science Dept., 
Pittsburgh, PA 15213-3890; A. Pnueli, 
Weizmann Inst., Rehovot, Israel; or J. 
Sifakis, LGI-IMAG, BP 53X, 38041 Greno¬ 
ble Cedex, France. 

ICAIL 89, Second Int’l Conf. on Artificial 
Intelligence and Law, June 13-16, Vancou¬ 
ver, Canada. Contact Robert T. Franson or 
Joseph C. Smith, Faculty of Law, Univ. of 
British Columbia, Vancouver, B.C., 
Canada, phone (604) 228-2323. 

Int’l Conf. on Software Engineering and 
Knowledge Engineering, June 15-17, 


Alumni Hall, Pittsburgh, PA 15260, phone 
(412) 624-8490. 

First Symp. on Parallel Algorithms and 
Architectures, June 18-21, Santa Fe, N.M. 
Sponsor: ACM. Contact Tom Leighton, 

Math Dept, and Computer Science Lab, 

MIT, Cambridge, MA 02139. 

i£32l Int’l Workshop on Hardware Fault 
Hz Tolerance in Multiprocessors, June 
19-20, Urbana, Ill. Contact Prith Banerjee, 
Coordinated Science Lab, Univ. of Illinois, 
1101 W. Springfield Ave., Urbana, IL 
61801, phone (217) 333-6564. 

CHDL 89, Ninth Int’l Symp. on Com- 
puter Hardware Description Languages 
and Applications, June 19-21, Washington, 
DC. Cosponsors: IFIP, ACM. Contact John 
A. Darringer, IBM T. J. Watson Research 
Center, PO Box 218, Yorktown Heights, NY 
10598, phone (914) 945-1018. 

Sixth Int’l Workshop on Database 
Machines, June 19-21, Deauville, France. 
Sponsors: INRIA, AFCET. Contact Haran 
Boral, MCC, 3500 W. Balcones Center Dr., 
Austin, TX 78759 (in the US); or Pascal 
Faudemay, Masi Labo., Univ. of Paris 6, 4 
Place Jussieu, 75252 Paris, Cedex 05, France 
(outside the US). 

ICNN 89, Int’l Conf. on Neural Networks, 
June 19-22, Washington, DC. Sponsor: 
IEEE. Contact Nomi Feldman, 3770 Tansy 
St., San Diego, CA 92121, phone (619) 
453-6222. 

£3^ Fourth Structure in Complexity Theory 
^7 Conf., June 19-22, Eugene, Ore. 
Cosponsors: Univ. of Oregon, ACM. Con¬ 
tact Stephen R. Mahaney, Rm. 2C-454, 
AT&T Bell Labs, 600 Mountain Ave., Mur¬ 
ray Hill, NJ 07974. 

Graphics Interface 89, June 19-23, London, 
Ont., Canada. Sponsor: Canadian Man- 
Computer Communications Society. Contact 
Irene Gargantin, Computer Science Dept., 
Univ. of Western Ontario, London, Ont., 
Canada N6A 5B7, phone (519) 661-3563. 

Vision Interface 89, June 19-23, London, 
Ont., Canada. Sponsor: Canadian Image 
Processing and Pattern Recognition Society. 
Contact Irene Gargantin, Computer Science 
Dept., Univ. of Western Ontario, London, 
Ont., Canada N6A 5B7, phone (519) 
661-3563. 

® NECC 89, 10th National Educational 
Computing Conf., June 20-22, Boston. 
Cosponsor: Int’l Council for Computers in 
Education. Contact Michael C. Mulder, 
Applied Research, Univ. of Portland, 5000 
N. Willamette Blvd., Portland, OR 97203, 
phone (503) 283-7433; or NECC 89, ICCE, 
Univ. of Oregon, 1787 Agate St., Eugene, 
OR 97403-9905. 

Third Electronics Materials and Process 
Conf., June 20-22, Los Angeles. Sponsor: 


Chicago. Contact Shi-Kuo Chang, Computer Society for the Advancement of Material and 
Science Dept., Univ. of Pittsburgh, 322 Process Engineering. Contact Marge Smith, 


FTCS 19, Int’l Fault-Tolerant Corn¬ 
s' puting Symp., June 21-23, Chicago. 
Contact S.M. Reddy, FTCS 19, Electrical 
and Computer Engineering Dept., Univ. of 
Iowa, Iowa City, IA 52242, phone (319) 
335-5196; or Ravi K. Iyer, Coordinated 
Science Lab, Univ. of Illinois, 1101 W. 
Springfield Ave., Urbana, IL 61801, phone 
(217)333-9732. 

Third Int’l Conf. on Foundations of Data 
Organization and Algorithms, June 21-23, 

Paris. Sponsor: INRIA. Contact Witold Lit- 
win, INRIA Rocquencourt, c/o Public Rela¬ 
tions Dept., Domaine de Voluceau, 78153 Le 
Chesnay Cedex, France, phone 33 (1) 
39-63-56-00. 

SIGPIan 89, Conf. on Programming Lan¬ 
guage Design and Implementation, June 
21-23, Portland, Ore. Sponsor: ACM. Con¬ 
tact Bruce Knobe, Prime Computer, Inc., 

500 Old Connecticut Path, Framingham, 

MA 01701, phone (508) 879-2960. 

^ Second Symp. on Computer-Based 
W Medical Systems, June 25-27, Min¬ 
neapolis, Minn. Cosponsors: IEEE, Univ. of 
Minnesota. Contact John M. Long, 2829 
University Ave. SE, #408, Minneapolis, MN 
55414, phone (612) 627-4850; or Bart Galle, 
Continuing Medical Education, Univ. of 
Minnesota, Box 202 UMHC, 420 Delaware 
St. SE, Minneapolis, MN 55455, phone (612) 
626-5525. 

£3^ CAR 89, Computer-Assisted Radioi- 
n 37 ogy Conf., June 25-28, Berlin. 
Cosponsor: AMK Berlin. Contact Michael 
L. Rhodes, MPDI, 2730 Pacific Coast Hwy., 
Torrance, CA 90505, phone (213) 539-5944. 

£3^ DAC 89, 26th Design Automation 
NS7 Conf., June 25-29, Las Vegas. 
Cosponsor: ACM. Contact Michael J. 
Lorenzetti, MCNC, PO Box 12889, Research 
Triangle Park, NC 27709-2889; or Pat 
Pistilli, MP Associates, 7490 Clubhouse Rd., 
Suite 102, Boulder, CO 80301, phone (303) 
530-4333. 

£3^ Hot Chips Symp., June 26-27, Palo 
^S7 Alto, Calif. Sponsor: IEEE Computer 
Society Technical Committee on Micro¬ 
processors and Microcomputers. Contact 
Robert Stewart, Stewart Research Enter¬ 
prises, 1658 Belvoir Dr., Los Altos, CA 
94022, phone (415) 941-6699. 

Int’l Assoc, of Knowledge Engineers Conf., 
June 26-28, College Park, Md. Cosponsors: 
IAKE, Univ. of Maryland. Contact Fred 
Whiting, IAKE Conf., Georgetown PO Box 
25461, Washington, DC 20007, phone (301) 
231-7826. 

Int’l Conf. on Mathematics of Program 
Construction, June 26-30, Groningen, The 
Netherlands. Contact Jan L.A. van de Snep- 
scheut. Mathematics and Computing Science 
Dept., Groningen Univ., PO Box 800, 9700 
AV Groningen, The Netherlands. 
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Int I Conf. on Expert Planning Systems, 
June 27-29, Brighton, England. Sponsor: 
Institution of Electrical Engineers. Contact 
Conf. Services, IEE, Savoy PI., London 
WC2R OBL, UK, phone 44 (1) 240-1871, ext. 


IFCS 89, Second Conf. of the Int'l Federa¬ 
tion of Classification Societies, June 27-30, 

Charlottesville, Va. Contact IFCS 89, 
Mathematics Dept., Univ. of Virginia, Char¬ 
lottesville, VA 22903, phone (804) 924-4919 


July 1989 

SETSS 90, Seventh Int’l Conf. on Software 
Engineering for Telecommunications Switch¬ 
ing Systems, July 3-6, Bournemouth, 
England. Sponsor: Institution of Electrical 
Engineering. Contact Conf. Services, IEE, 
Savoy PL, London WC2R OBL, UK, phone 
44(01)24-01-871. 

EKAW 89, Third European Knowledge 
Acquisition for Knowledge-Based Systems 
Workshop, July 3-7, Paris. Contact John 
Boose, Advanced Technology Center, Boe¬ 
ing Computer Services, 7L-64, PO Box 
24346, Seattle, WA 98124, phone (206) 
865-3253; or Brian Gaines, Dept, of Com¬ 
puter Science, Univ. of Calgary, 2500 Uni¬ 


versity Dr. NW, Calgary, Alta., Canada 
T2N 1N4, phone (403) 220-5901. 


Management, Imperial College, London 
SW7 2PG, UK (in other regions). 


ICALP 89, 16th Colloquium on Automata, 
Languages, and Programming, July 11-15, 

Stresa, Italy. Sponsor: European Assoc, of 
Theoretical Computer Science. Contact Ron- 
chi Della Rocca, Dip. di Informatica, corso 
Svizzera 185, 10149 Torino, Italy, phone 39 
(11) 75-56-77. 

Eighth Australia Conf. on Microelectronics: 
July 12-14, Brisbane, Australia. Cosponsors: 
IEEE Queensland Section, Univ. of Queens¬ 
land. Contact Microelectronics 89, Institu¬ 
tion of Engineers, Australia, 11 National 
Circuit, Barton ACT 2600, Australia, phone 
61 (62) 706-549. 


Symp. on Design and Implementation of 
Large Spatial Databases, July 17-18, Santa 
Barbara, Calif. Contact Oliver Gunther, 
Computer Science Dept., Univ. of Califor¬ 
nia, Santa Barbara, CA 93106, phone (805) 


TO CASE 89, Third Int’l Workshop on 
'*30 Computer-Aided Software Engineer¬ 
ing, July 17-21, London. Cosponsors: 
Imperial College of London et al. Contact 
Elliot Chikofsky, Index Technology Corp., 1 
Main St., Cambridge, MA 02142 (in North 
America); or John Jenkins, School of 


Third Int’l Conf. on Image Processing, July 
18-20, Warwick, England. Sponsor: Institu¬ 
tion of Electrical Engineers. Contact Conf. 
Services, IEE, Savoy PL, London WC2R 
OBL, phone 44 (1) 24-01-871, ext. 222. 

89 VLSI Education Conf. and Exposition 
July 19-21, Santa Clara, Calif. Contact M. 
Bush, Conf. Management Services, 5 
Cleland PL, Menlo Park, CA 94025, phone 
(415) 329-0510. 


Summer Computer Simulation Conf., July 
24-27, Austin, Texas. Sponsor: Society for 
Computer Simulation. Contact SCS, PO 
Box 17900, San Diego, CA 92117-7900, 
phone (619) 277-3888. 


1989 Int’l Computers in Engineering Conf., 
July 30-Aug. 2, Anaheim, Calif. Sponsor: 
ASME. Contact Donald R. Riley, Mechani¬ 
cal Engineering Dept., Univ. of Minnesota, 
111 Church St. SE, Minneapolis, MN 55455. 


puter Graphics and Interactive Tech¬ 
niques, July 30-Aug. 4, Boston. Cosponsor: 
ACM. Contact Chris Herot, Javelin Soft¬ 
ware, 1 Kendall Square, Bldg. 200, Cam¬ 
bridge, MA 02139. 


NEW STUDIES IN: 


CONCURRENT SYSTEMS 


CONCURRENT COMPUTATIONS 
Algorithms, Architecture, and Technology 

edited by Stuart K. Tewksbury, Bradley W. Dickinson, 
and Stuart C. Schwartz 

Leading researchers in the theory, architecture, fault tolerance, 
and technology of concurrent computational systems present 
topical reviews highlighting advanced technologies, novel ar¬ 
chitectures, and theoretical concepts. Taken together these 
papers provide a broad overview of potentials and techniques 
for future systems. 

0-306-42939-X/proceedings/738 pp./ill./1988/S95.00 

Forthcoming . . . 

DEFECT AND FAULT TOLERANCE 
IN VLSI SYSTEMS 

edited by Israel Koren 

In this volume, representatives from industry and academia 
discuss mutual interests in defect-tolerant architectures and 
models for integrated circuit defects, faults, and yield. Sections 
are devoted to defect monitoring and yield projection, testing 
and more 3 E deS ’ gnS ’ reconfi 8 urabl e arrays, fault-tolerant arrays, 

0-306-43224-2/proceedings/approx. 400 pp./ill./1989 


Forthcoming. . . 

COMPUTER NETWORK 
ARCHITECTURES AND PROTOCOLS 

Second Edition 
edited by Carl A. Sunshine 

Building on the framework created in the first edition by Paul 
Green, the second edition has been substantially revised and up¬ 
dated to reflect current theory and applications. Entirely new 
papers have been added on the emerging higher layer OSI 
standards, and on the IBM and Xerox network systems. A 
volume in the series Applications of Communications Theory. 
0-306-43189-0/approx. 625 pp./ill./1989 
Forthcoming. . . 

SCIENTIFIC COMPUTING 
ON SUPERCOMPUTERS 

edited by Jozef T. Devreese and Piet E. Van Camp 

This compilation updates the latest information in scientific high 
speed computing. Numerous papers are presented concerning 
supercomputer architecture, supercomputer languages and 
algorithms, and supercomputer applications. 
0-306-43217-X/proceedings/approx. 325 pp./ill./1989 
Book prices are 20% higher outside the US & Canada. 
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August 1989 

18th lnt’1 Conf. on Parallel Processing, Aug. 
8-12, St. Charles, Ill. Sponsor: Pennsylvania 
State Univ. Contact Tse-yun Feng, College 
of Engineering, Electrical Engineering Dept., 
Pennsylvania State Univ., 121 Electrical 
Engineering East, University Park, PA 
16802, phone (814) 865-7667. 

28th Technical Symp.: Aug. 14, Gaithers¬ 
burg, Md. Sponsors: Washington, DC Chap¬ 
ter of ACM, NIST. Contact Milton S. Hess, 
American Management Systems, 1525 Wil¬ 
son Blvd., Arlington, VA 22209, (703) 
841-5942. 

32nd Midwest Symp. on Circuits and Sys¬ 
tems, Aug. 14-15, Urbana, Ill. Sponsors: 
Univ. of Illinois at Urbana-Champaign, 
IEEE. Contact K.S. Arun, Coordinated 
Science Lab, Univ. of Illinois, 1101 W. 
Springfield Ave., Urbana, IL 61801-3082, 
phone (217) 333-7678. 

Micro 22, 22nd Workshop on Micropro¬ 
gramming and Microarchitecture: Aug. 

14- 16, 1989, Dublin, Ireland. Contact 
Gearold R. Johnson, Center for Computer 
Assisted Engineering, Colorado State Univ., 
Fort Collins, CO 80523, phone (303) 
491-5543. 

Third Pan Pacific Computer Conf., Aug. 

15- 19, Beijing. Sponsors: Chinese Computer 
Federation, Chinese Inst, of Electronics. 
Contact Halbrecht Associates, 1200 Summer 
St., Stamford, CT 06905, phone (203) 
327-5630. 

VLSI 89, Int'l Conf. on Very Large Scale 
Integration, Aug. 16-18, Munich, West Ger¬ 
many. Sponsor: IFIP. Contact VLSI 89, Sie¬ 
mens AG, Otto-Hahn-Ring 6, 8000 Munich 
83, Federal Republic of Germany, phone 49 
(89) 63-64-60-38. 

Crypto 89, Aug. 20-24, Santa Barbara, 

Calif. Sponsor: Int’l Assoc, for Cryptologic 
Research. Contact Kevin McCurley, IBM 
Research, K53/802, 650 Harry Rd„ San 
Jose, CA 95120-6099, phone (408) 927-1708. 

1JCA1 89, 11th Int’l Joint Conferences on 
Artificial Intelligence, Aug. 20-26, Detroit. 
Sponsors: Int’l Joint Conferences on Artifi¬ 
cial Intelligence, Inc., AAAI. Contact Wolf¬ 
gang Bibel, Computer Science, Univ. of 
British Columbia, 6356 Agricultural Rd., 
Vancouver, B.C., V6T 1W5, Canada, phone 
(604) 228-3061. 

Beijing Int’l Symp. for Young Computer 
Professionals, Aug. 21-23, Beijing. Spon¬ 
sors: China Assoc, for Science and Technol¬ 
ogy, Chinese Computer Federation. Contact 
Siping Zhang, Inst, of Computing Technol¬ 
ogy, Academia Sinica, PO Box 2704, Beij¬ 
ing, China 100080. 

Working Conf. on Engineering for Human- 
Computer Interaction, Aug. 21-25, Napa 
Valley, Calif. Sponsor: IFIP. Contact 
Leonard Bass, Software Engineering Inst., 


Carnegie Mellon Univ., Pittsburgh, PA 
15213-3890; or Claus Unger, Praktische 
Informatick II, Univ. of Hagen, Feithstr 
140, D-5800 Hagen, West Germany. 

ITC 89, Int’l Test Conf., Aug. 27-31, 
Washington, DC. Contact Doris 
Thomas, ITC 89, PO Box 264, Mt. Free¬ 
dom, NJ 07970, phone (201) 895-5260. 

Congress 89, 11th World Computer Con¬ 
gress, Aug. 28-Sept. 1, San Francisco. Spon¬ 
sor: IFIP. Contact Congress 89, PO Box 
18-P, Denver, CO 80218, phone (303) 
831-6338; or Adrian J. Basili, AT&T, 30 
Knightsbridge Rd., Piscataway, NJ 08854. 


September 1989 

ASE 89, Int’l Conf. on Applications of 
Supercomputers in Engineering, Sept. 5-7, 

Southampton, England. Contact Liz New¬ 
man, Computational Mechanics Inst., 
Ashurst Lodge, Ashurst, Southampton, S04 
2AA, England, UK, phone 44 (0) 42-12- 
92-853. 

12th Int’l Conf. on Fault-Tolerant Systems 
and Diagnostics, Sept. 5-7, Prague, Czecho¬ 
slovakia. Sponsor: Czechoslovak Scientific 
and Technical Society. Contact Jan 


Hlavicka, Czech Technical Univ., Dept, of 
Computers, Prague, CSSR. 

1CIP 89, Int’l Conf. on Image Processing, 
Sept. 5-8, Singapore. Sponsors: IEEE Singa¬ 
pore Section, National Univ. of Singapore. 
Contact Meeting Planners Pte. Ltd., 100 
Beach Rd., No. 33-01, Shaw Towers, Singa¬ 
pore 0718, Republic of Singapore, phone 
(65) 297-2822. 

ARITH 9, Ninth Symp. on Computer 
Arithmetic, Sept. 6-8, Santa Monica, 
Calif. Contact Algirdas Avizienis, Computer 
Science Dept., Univ. of California at Los 
Angeles, 4731G Boelter Hall, Los Angeles, 
CA 90024, phone (213) 825-3028. 

Seventh Pacific Northwest Software Quality 
Conf., Sept. 11-12, Portland, Ore. Contact 
Dick Hamlet, Computer Science Dept., 
Portland State Univ., PO Box 751, Portland, 
OR 97207-0751. 

European Software Engineering Conf., Sept. 
11-15, Warwick, England. Sponsor: British 
Informatics Society Limited. Contact BISL, 
13 Mansfield St., London W1M OBP, UK, 
phone 01-637-0471. 

35th IEEE-Holm Conf. on Electrical Con¬ 
tacts, Sept. 18-20, Chicago. Contact IEEE- 
Holm Conf., IEEE Headquarters, 345 E. 


CONFERENCE ’89 


Graphics Interface ’89 
Vision Interface ’89 


June 19-23 Juin, 1989, Radisson Hotel, London, Ontario, Canada 


Sponsored by 

Canadian Man-Computer Communication Society (CMCCS) and 
Canadian Image Processing and Pattern Recognition Society (CIPPRS) 
General Chairman: Irene Gargantini, The University of Western Ontario 
Programme Chairmen: Pierre Boulanger, Terry Caelli, Marceli Wein. 


Conference Features 

Internationally Known Experts in Graphics and Image Processing - Workshop - 

Tutorials - Invited Speakers - Contributed Papers - Open Forum - Computer Exhibit 

- Electronic Theatre - Conference Proceedings and Tutorial Materials 

Programme Highlights 

. Graphics Interface Papers Presented on: ‘Modeling, ‘User Interface, *Algorithms, 
♦Paint/Draw, ‘Visualization, ‘Rendering, ‘Systems and Applications. 

• Vision Interface Papers Presented on: ‘Segmentation, ‘Range Image Understanding, 
‘Hardware, ‘Motion and Optical Flow, ‘Pattern Recognition, ‘Object Recognition and 
Scene Understanding . 

• Workshop on: ‘Range Image Understanding. 

• Tutorials on: ‘Ray Tracing, ‘Visual Motion Analysis, ‘Hierarchical Data Structures 
for Computer Graphics, ‘Contemporary Issues in Computer Aided Design and 
Computer Graphics. 

Registration Material and Information is available from 
Marlis Ziprick, Local Arrangements Chair, Department of Computer Science 
The University of Western Ontario, London, Ontario, Canada N6A 5B7 
Phone: 519-661-3540* E-Mail: marlis@chris.uwo.ca • FAX: 519-661-3292 












47th St., New York, NY 10017-2394, phone 
(212) 705-7405. 


Compsac 89, 13th Int’l Computer Soft- 
ware and Applications Conf., Sept. 
18-22, Kissimmee, Fla. Contact IEEE Com¬ 
puter Society, 1730 Massachusetts Ave. NW, 
Washington, DC 20036-1903, phone (202) 
371-0101. 


Istituto di Cibernetica, C.N.R., 1-80072 
Arco Felice, Naples, Italy, phone 39 (81) 
867-1255. 


® CSM 89, Conf. on Software Main¬ 
tenance, Sept. 25-28, Pensacola, Fla. 
Contact CSM 89, IEEE Computer Society, 
1730 Massachusetts Ave. NW, Washington, 
DC 20036-1903, phone (202) 371-0101. 


151, Toronto, Ont., Canada M8Z 5S4, 
phone (416) 231-4111. 


^ second 


i Operating Systems, Sept. 27-29, 

Pacific Grove, Calif. Contact Joseph 
Boykin, Encore Computer, 257 Cedar Hill 
St., Marlborough, MA 01752, phone (617) 
460-0500. 


HCI Int’l 89, Third Int’l Conf. on Human- 
Computer Interaction, Sept. 18-22, Boston. 
Contact Michael J. Smith, Industrial 
Engineering Dept., Univ. of Wisconsin, 1513 
University Ave., Madison, WI 53706, phone 
(608)263-6329. 

Network Management and Control Work¬ 
shop, Sept. 19-21, Tarrytown, NY. Spon¬ 
sors: IEEE et al. Contact Ivan Frisch, Center 
for Advanced Technology in Telecommuni¬ 
cations, Polytechnic Univ., 333 Jay St., 
Brooklyn, NY 11201, phone (718) 260-3050. 

Systems Science X Int’l Conf., Sept. 19-22, 
Wroclaw, Poland. Contact Jerzy Swiatek, 
Technical Univ. of Wroclaw, Inst, of Con¬ 
trol and Systems Engineering, Janiszewski 
St. 11/17, 50-370 Wroclaw, Poland. 

Fifth Int’l Conf. on Image Analysis and Pro¬ 
cessing, Sept. 20-22, Positano, Italy. Spon¬ 
sors: Int’l Assoc, for Pattern Recognition et 
al. Contact Gabriella Sanniti di Baja, c/o 


® ASIC Seminar and Exhibit, Sept. 

25-28, Rochester, N.Y. Contact Lynne 
M. Engelbrecht, 170 Mt. Read Blvd., Roch¬ 
ester, NY 14611, phone (716) 328-2310. 


October 1989 


Hth Electrical Overstress/Electrostatic Dis¬ 
charge Symp., Sept. 26-28, New Orleans. 
Sponsors: IIT Research Inst., EOS/ESD 
Assoc. Contact Bob Rountree, Texas Instru¬ 
ments, 12201 Southwest Frwy., MS 631, 
Houston, TX 77001, phone (713) 274-4077. 


Third Int’l Workshop on Distributed 
Algorithms, Sept. 26-28, Nice, France. Con¬ 
tact Jean-Claude Bermond, LRI, Bat 490, 
Universite Paris-Sud, 91405 Orsay, France. 


Performance Evaluation, Reliability, 
and Exploitation of Computer Sys¬ 
tems, Sept. 26-29, Walbrzych, Poland. 
Sponsors: Polish Informatic Society et al. 
Contact George J. Anders, Stations and 
Underground Section, Electrical Research 
Dept., Ontario Hydro, 800 Kipling Ave., KR 


ICCD 89, IEEE Int’l Conf. on Com¬ 
as' puter Design, Oct. 2-4, Cambridge, 
Mass. Contact Sumit Das Gupta, IBM, Bldg. 
306, ZIP 3A1, Hopewell Junction, NY 
12533, phone (914) 894-0540. 

Second Int’l Workshop on Software 
Configuration Management, Oct. 3-6, 

Princeton, N.J. Cosponsors: ACM, Gesell- 
schaft fiir Informatik. Contact Thomas 
Murphy, Siemens Research, 755 College Rd. 
E, Princeton, NJ 08540, phone (609) 
734-6560. 

Eighth Symp. on Reliable Distributed 
XS7 Systems, Oct. 10-12, Seattle, Wash. 
Contact Jane W.S. Liu, Computer Science 
Dept., Univ. of Illinois, Urbana, IL 61801, 
phone (217) 333-0135. 


„ Call for Papers 

Hawaii International Conference on System Sciences - 23, Kona, Hawaii, January 3-6,1990 


iNO ELECTRONICS ENGINEERS. INC 
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Rapid Software Prototyping, Luqi, Naval Postgraduate School 

•Fundamental computational models and prototyping lai^guLges^ Evaluating the 
S. liT,°" Of prototype systems . Transformation of prototypinglanguages into implementfton 

S^aSs&SS ^ dCSlgn * SpCCialhuman interfaces ’ & A dynamic!in dSSs“for 

Specification-based Software Construction, B. Kraemer, GMD & Luqi, Naval Postgraduate School 









CALL FOR PAPERS 


Ninth Annual IEEE 



[NTERNATIONAL 

Phoenix 

CONFERENCE on, 
COMPUTERS and 
COMMUNICATIONS 


♦ 


Sponsored by: 

INSTITUTE OF ELECTRICAL AND 
ELECTRONIC ENGINEERS 
and 

THE IEEE COMMUNICATIONS SOCIETY 

In conjunction with: 

THE IEEE COMPUTER SOCIETY, 

THE PHOENIX IEEE SECTION 
THE TUCSON IEEE SECTION 
THE UNIVERSITY OF ARIZONA 
and 

ARIZONA STATE UNIVERSITY 


CONFERENCE CHAIRMAN: 
Dr. Forouzan Golshani 
Dept, of Computer Science 
Arizona State University 
Tempe, AZ 85287 
(602) 965-2855 
golshani@asuvax.asu.edu 

PROGRAM CHAIRMAN: 

Dr. Ralph Martinez 
ECE Dept. 

The University of Arizona 
Tucson, AZ 85721 
(602) 621-6174 

martinez%ecevax@rvax.ccit.arizona.edu 


IMPORTANT DATES: 

Submission Deadline 

14 July 1989 

Acceptance Notification 

15 September 1989 

Camera Ready Version Due 
1 December 1989 

Conference Dates 
21-23 March 1990 


March 21-23,1990 

Scottsdale, Arizona 

This international conference provides a forum for the 
presentation and exchange of current work in the fields of 
computers and communications, and their applications 
areas. Topics of interest include theory, design, simulation, 
implementation, applications, and evaluation aspects in the 
major areas listed. 

The Program Committee invites original papers of no longer 
than 5,000 words on any area in computers and com¬ 
munications. The list of areas represents suggested topics 
for papers. 

The submitted manuscript must be typed double-spaced 
and must include an Abstract of 300 words. Long papers and 
reports will not be considered. United States authors should 
obtain company and government clearances prior to sub¬ 
mission of the papers. 

Please submit five copies of complete Paper and Abstract by 
14 July 1989 to: 

Dr. Ralph Martinez, Program Chairman 
Electrical and Computer Engineering 
The University of Arizona 
Tucson, AZ 85721 
(602) 621-6174 

All papers submitted will be refereed by the Program 
Committee. They will be judged with respect to their 
quality, originality, and relevance. Authors will be notified 
of acceptance/rejection shortly after September 15, 1989. 
Accepted papers will be published in the IPCCC Proceedings. 

SPECIAL SESSIONS 

We also solicit proposals for special topics and panel 
sessions. Each proposal should include subject, justification, 
and names of possible participants. Proposers will be 
notified of acceptance/rejection by August 11,1989. 

TUTORIALS 

Proposals for one-day tutorials should be sent to: 

James A. Weeldreyer, Tutorials Chairman 
Manager, Custom Software Development, IASD 
Honeywell Inc. 

16404 North Black Canyon Highway 
Phoenix, Arizona 85023. 

(602) 863-5983 


IPCCC 1990 TOPIC AREAS: 

Computer Technology 

• Parallel Computing and Fault Tolerance 

• Neural Network Computing 

• DSP and Imaging Architectures 

• Distributed Data Base Systems 

• Optical Disk Storage 
Communications Technology 

• Fiber Optics 

• Photonic Switching 

• Satellite/Terrestrial Systems 

• Communications Theory 

• Spread Spectrum 
Software Systems 

• Development Enviroments 

• Object-Oriented Systems 

• Real-Time Applications 

• Design, Specification and Coding 

• Performance Evaluation/Measurement 

• Graphics and Scientific Visualization 
Networking Systems 

• ISO/OSI Networks and Interoperability 

• Backbone Networks 

• Local/Wide Area Networks 

• Network Management/Control/Security 

• ISDN Systems 
Al/Expert Systems 

• Expert System Design/Applications 

• Non-traditional Languages 

• Robotics and Computer Vision 

• Distributed Al Systems 

• Intelligent Database 
Medical Information Technology 

• Hospital Information Systems 

• Radiological Information Systems 

• Image Archiving and 
Communications Systems 

• Medical Imaging Systems 

• Interactive Imaging Workstations 

VLSI/VHSIC 

• Manufacturing Technology 

• 1C Microcontamination 
. Application Specific ICs 

• GaAs Devices 

• 1C Design Tools 








RATES: $12.00 per line, $120 
minimum charge (up to ten lines). 
Average five typeset words per line, eight 
lines per column inch. Add $10 for box 
number. Send copy at least one month 
prior to publication to: Heidi Rex or 
Marian Tibayan, Classified Advertis¬ 
ing, COMPUTER Magazine, 10662 Los 
Vaqueros Circle, Los Alamitos, CA 
90720; (714) 821-8380. 

In order to conform to the Age Discrimi¬ 
nation in Employment Act and to dis¬ 
courage age discrimination, COMPUTER 
may reject any advertisement containing 
any of these phrases or similar ones: 
“...recent college grads...,” “...1-4 years 
maximum experience...,” “...up to 5 years 
experience...,” or “...10 years maximum 
experience." COMPUTER reserves the 
right to append to any advertisement, 
without specific notice to the advertiser, 
“Experience ranges are suggested mini¬ 
mum requirements, not maximums.” 
COMPUTER assumes that, since adver¬ 
tisers have been notified of this policy in 
advance, they agree that any experience 
requirements, whether stated as ranges or 
otherwise, will be construed by the reader 
as minimum requirements only. 


THE UNIVERSITY OF TENNESSEE 

Department of Computer Science 

Knoxville, Tennessee 37996-1301 

The Department of Computer Science in¬ 
vites applications for tenure-track positions at 
the rank of Professor beginning Spring 1989. 
A strong research record in the areas of com¬ 
puter graphics, networking, or operating sys¬ 
tems is sought but all major fields in com¬ 
puter science may be considered. Experi¬ 
ence directing doctoral students is especially 
important. Tenure-track positions for Associ¬ 
ate and Assistant Professors are also open. 
Applicants for Associate Professor should 
have a strong research record, preferably in 
the above-named areas; experience direct¬ 
ing doctoral students is desirable. Applicants 
for Assistant Professor should have a strong 
interest in research, preferably in the above- 
named areas. Applicants for all positions 
should have a doctoral degree in computer 
science or a related area. 

Departmental SUN, IBM and DEC work¬ 
stations abound for students and faculty and 
are fully networked. The University operates 
an IBM 3090 and a large VAX cluster. 
CRAY, HYPERCUBE, SEQUENT and 
other machines are available via high speed 
link with Oak Ridge National Laboratory. 

You can respond to straight@utkvx.utk. 
edu. The mailing address is Department of 
Computer Science, 107 Ayres Hall, The 
University of Tennessee, Knoxville TN 
37996-1301. 

The University of Tennessee is an EEO/ 
AA/TITLE IX/SECTION 504 employer. 


UNIVERSITY OF WASHINGTON 

The University of Washington seeks can¬ 
didates for tenure-track faculty appointments 
in computer science/engineering starting in 
the 1989-90 academic year. Applications 
from outstanding individuals in all areas 
of computer science/engineering will be 
considered. 

A moderate teaching load allows time for 
quality research and close involvement with 
students. We expect applicants to have a 
strong commitment to both research and 
teaching, and an outstanding record of 
research for their level. Any appointment 
should bring significant new research 
strength to the University. 

Interested applicants should send a letter 
of application, a resume, and the names of 
four references to: Computer Science/Engi¬ 
neering Faculty Recruiting Committee, 
FR-35, University of Washington, Seattle 
WA 98195. 

The University of Washington is an Affir¬ 
mative Action/Equal Opportunity Employer. 
The Ph.D. is required for these positions. 


NAVAL POSTGRADUATE SCHOOL 
Computer Science 

The Computer Science Department in¬ 
vites applications for faculty positions at all 
levels. Our primary interests are in the areas 
of operating systems and programming lan¬ 
guages. Our secondary interests are in the 
areas of visual data processing, graphics, 
and computer architecture (especially real¬ 
time and parallel-processing aspects of the 
three). Applicants should have a Ph D. in 
Computer Science or a closely related field 
and be committed to high-quality teaching 
and research. Senior applicants must have 
distinguished research records. Appoint¬ 
ments can begin at any time. 

The Department offers M.S. and Ph D. 
degrees in computer science, but no under¬ 
graduate degrees. Currently, 110 students 
are enrolled in the M.S. program and five in 
the Ph.D. program. Students are military of¬ 
ficers or civilian employees of the Depart¬ 
ment of Defense and are fully supported by 
their sponsoring organization during their 
studies. Departmental facilities (supported 
by eight full-time computer professionals) in¬ 
clude six instructional and research labora¬ 
tories with extensive state-of-the-art equip¬ 
ment. Faculty normally teach for two quarters 
and perform research for two quarters per 
year. The Monterey-Carmel area provides a 
pleasant coastal climate and easy access to 
Silicon Valley companies. 

Send a detailed resume, an abstract of 
your best recent research, and letters of 
reference to Faculty Search Committee, 
Computer Science, Code 52, Naval Post¬ 
graduate School, Monterey, CA 93943 
(phone (408) 646-2449). An Equal Oppor¬ 
tunity/Affirmative Action Employer. 


CARNEGIE MELLON UNIVERSITY 

Faculty Position in Field Robotics/ 

Construction Automation /Sensing 

Carnegie Mellon University, Department 
of Civil Engineering, invites applications for a 
tenure-track position as an Assistant Profes¬ 
sor to begin in September 1989. Candidates 
for this position should have an earned doc¬ 
torate and research experience in field robot- 
ics, remote sensing or construction automa¬ 
tion, and must be able to interact with other 
faculty working in robotics, computer-aided 
engineering and construction project manage¬ 
ment. Candidates should have strong analyti¬ 
cal capabilities (preferably in mechanics or 
contol) and/or experience with micropro¬ 
cessor-based systems, sensors and instru¬ 
mentation . While a background in engineer¬ 
ing is necessary, training in civil engineering 
is not a requirement. Responsibilities include 
teaching undergraduate and graduate 
courses, supervising graduate students and 
developing a funded research program. Cur¬ 
rent field robotics/construction automation 
activities (including fundamental studies in 
mobility, vision, force sensing, and system 
integration) in the department are well es¬ 
tablished, and many opportunities exist for 
professional and intellectual growth. The de¬ 
partment also has close ties with the univer¬ 
sity’s Robotics Institute, and a joint appoint¬ 
ment with the Robotics Institute is possible. 
Interested persons should contact Professor 
Chris Hendrickson, Faculty Search Commit¬ 
tee, Department of Civil Engineering, Car¬ 
negie Mellon University, Pittsburgh, PA 
15213-3890. Carnegie Mellon is an equal 
opportunity/affirmative action employer. 


UNIVERSITY OF WISCONSIN- 
MADISON 
Faculty Positions 

The Department of Electrical and Com¬ 
puter Engineering invites applications for 
tenure and tenure-track positions. A Ph.D. 
degree is required, and successful candi¬ 
dates are expected to participate in both 
teaching and research activities. Applicants 
in all areas of computer engineering are in¬ 
vited to apply, but the following areas are of 
special interest: Computer architecture, 
computer networks, VLSI and computer- 
aided design, microprocessor and minicom¬ 
puter applications, real-time control and in¬ 
strumentation applications, and engineering 
applications of artificial intelligence. Rank 
and salary will be commensurate with qualifi¬ 
cations and experience. Send resume and 
names of three references to J. Leon 
Shohet, Chairman, Department of Electrical 
and Computer Engineering, University of 
Wisconsin-Madison, 1415 Johnson Drive, 
Madison, WI 53706, an equal opportunity/ 
affirmative action employer. 
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TRINITY COLLEGE 
Computer Science 

Pending approval by the Board of Trustees, 
applications are invited for a tenure track 
position in Computer Science in the Depart¬ 
ment of Engineering and Computer Science 
at Trinity College starting in January 1990. 
The position involves undergraduate and 
graduate instruction and research. A doc¬ 
toral degree in Computer Science or equiva¬ 
lent is required. Applicants will be con¬ 
sidered in all areas of computer science that 
complement or strengthen our current cur¬ 
ricular/research programs. We are inter¬ 
ested in receiving applications from qualified 
women and minorities. Trinity College is an 
equal opportunity/affirmative action em¬ 
ployer. Please send resume to Professor 
Joseph D. Bronzino, Chairman, ECS De¬ 
partment, Trinity College, Hartford, CT 
06106. Consideration of applications will 
begin on May 1, 1989 and the search will re¬ 
main open until the position is filled. 


DEPARTMENT HEAD- 
COMPUTER SCIENCE 
University of Lowell 
Lowell, Massachusetts 

The faculty of Computer Science is seek¬ 
ing a new Department Head to provide 
leadership in reseach and to administer a 
comprehensive Graduate and Undergradu¬ 
ate program. This search will continue dur¬ 
ing the 1988-89 academic year or until the 
position is filled. The Department Head will 
be responsible for faculty recruitment and 
evaluation, development of a comprehen¬ 
sive research plan and the management of 
all departmental resources. A major priority 
is to recruit new faculty and expand research 
activity and the graduate program in Com¬ 
puter Science. 

The successful candidate must hold an 
earned doctorate in Computer Science or a 
directly related field and must be a citizen or 
permanent resident of the U.S. The candi¬ 
date should be nationally recognized and 
currently active in research and teaching in at 
least one area of modern Computer Sci¬ 
ence. Prior experience in academic and re¬ 
search administration sufficient to qualify for 
a tenured position at the rank of full professor 
is also required. 

For more information about the CS De¬ 
partment, see our prior ad in the January 
issue of IEEE Computer (p.76), ACM Com¬ 
munications or the Affirmative Action 
Register. Interested applicants are invited to 
forward a complete academic vitae and 
names of three references (two in his/her 
research area), and a letter stating his or her 
approach toward expanding research and 
graduate study in Computer Science at the 
University of Lowell. 

Address replies to: 

Professor Robert Lechner 
Department Head Search Committee 
Computer Science, WL229 
University of Lowell 
Lowell, MA 01854 

The University of Lowell is an Equal Op¬ 
portunity/Affirmative Action, Title IX, 504 
Employer. 


UNIVERSITY OF VERMONT 

The Department of Computer Science 
and Electrical Engineering has visiting faculty 
openings for September, 1989, in computer 
science. A doctorate in Computer Science, 
or the equivalent is required. The level of 
assistant or associate professor will be depen¬ 
dent upon the candidates qualifications. The 
responsibilities include teaching in main¬ 
stream computer science at both the under¬ 
graduate and graduate level in two or more 
of the following areas: operating systems, 
computer architecture, analysis of algo¬ 
rithms, computability theory, programming 
languages, language translators, as well as 
the presentation of an advanced graduate 
course or seminar. Computing facilities for 
both teaching and research are extensive. In 
particular, the Division of Engineering, 
Mathematics, and Business Administration 
supports an extensive UNIX-based com¬ 
puting facility, including a DEC VAX-11/ 
780, a DG MV-10000, a Sun 3/280, a Sun 
4/280, and a four-processor Encore 
Multimax, as well as numerous smaller 
machines and workstations, all intercon¬ 
nected by an extensive broadband and 
ethernet network. High technology com¬ 
panies in the area include IBM, DEC, GE 
and Simmonds Precision. The University of 
Vermont is an Affirmative Action Equal Op¬ 
portunity Employer and encourages applica¬ 
tions from women and members of minority 
groups. Applications will be accepted until 
positions are filled. Please send full resume, 
including information on teaching capabili¬ 
ties and research interests, as well as the 
names and addresses of three references to: 
Dr. Kenneth Golden, Chairperson; Univer¬ 
sity of Vermont; Department of Computer 
Science and Electrical Engineering; Votey 
Building; Burlington, VT 05405; (802) 656- 
3330. CSnet: cssearch@uvm.edu USEnet: 
. . . uunetluvm-genlcssearch 


CONCORDIA UNIVERSITY 
Centre for Pattern Recognition and 
Machine Intelligence (CENPARMI) 

CENPARMI is a new centre established in 
the Faculty of Engineering and Computer 
Science at Concordia University to foster 
close collaborations among active resear¬ 
chers in Pattern Recognition and Machine 
Intelligence and the industrial sector. 
Presently 10 faculty members and 35 re¬ 
search staff and graduate students are asso¬ 
ciated with the centre. 

CENPARMI invites applications for 
several post-doctoral and research positions 
in expert systems, pattern recognition, robo¬ 
tic planning and robot vision, starting Spring 
or Summer 1989. Candidates should have 
experience in one of the above areas. Send 
resume, reprints of publications, and the 
names of three or more references as soon as 
possible and before April 30, 1989 to Dr. 
C.Y. Suen, Director, Centre for Pattern 
Recognition and Machine Intelligence, 1455 
de Maisonneuve Boulevard West, Montreal, 
Quebec H3G 1M8, Canada. 

In accordance with Canadian Immigration 
requirements, this advertisement is directed 
in the first instance to Canadian citizens and 
permanent residents. 


TEST ENGINEER 

Test Engineer for mftr in NE Ohio to 
create advanced software to test various 
computer products using UNIX/C lan¬ 
guage; develop necessary test hardware to 
diagnose critical problems using Motorola 32 
bit microprocessors and advanced peripher¬ 
al chips; develop statistical process control 
with interface to manufacturing and resource 
planning (MRP) incorporating techniques of 
Artificial Intelligence and Expert Systems for 
high tech electronic industry as well as to 
evaluate systems compatability and provide 
feedback to engineering and mfg depart¬ 
ments. No experience is required in job 
described, but applicants will qualify with the 
following: M.S. in Computer Science; grad¬ 
uate-level courses in Artificial Intelligence 
(with applications), Data Management, Ex¬ 
pert Systems, and Database Management 
Systems; 1 year computer engineering ex¬ 
perience; and must be conversant with As¬ 
sembly and high level software languages 
such as UNIX/C and Unify Relational Data¬ 
base Management System as evidenced by 
academic coursework, publications or work 
experience. 40 hrs/wk, 8AM-5PM. 
$30,000/yr. Qualified applicants reply im¬ 
mediately with resume and course transcript 
to R. Lechler, JO# 1084417, Ohio Bureau 
of Employment Services, P.O. Box 1618, 
Columbus, Ohio 43216. 


STANFORD UNIVERSITY 

The Department of Electrical Engineering 
of Stanford University is seeking candidates 
for a tenured or tenure-track position in 
Fiber-Optic Telecommunications. The field 
of interest is interpreted broadly to include 
both systems and device aspects of optical 
communications. However, the individual 
we seek should have greatest strength and 
experience with systems, and in particular 
should be knowledgeable of the commercial 
telecommunications industry and its needs. 
Candidates should have excellent knowl¬ 
edge of the latest theoretical results and a 
proven skill in implementing such knowl¬ 
edge in “proof of concept” demonstrations. 
Simultaneously, he or she should have a 
good knowledge of the relevant device 
physics and technology. The appointment 
can be made at either a junior or a senior 
level, but the Department prefers a seasoned 
individual, possibly with industrial experi¬ 
ence, and having the potential to lead a 
larger telecommunications effort at Stanford. 
Applicants should have an earned Ph.D., 
demonstrated research ability, and a strong 
interest in graduate and undergraduate 
teaching. Stanford University is an Equal 
Opportunity Employer and welcomes appli¬ 
cations from women and members of minor¬ 
ity groups. Please submit, no later than May 
15, 1989, a detailed resume, a publication 
list, and the names of five references to Pro¬ 
fessor Allen Peterson, Chairman, Search 
Committee, Durand 227, Department of 
Electrical Engineering, Stanford University, 
Stanford, California 94305-4055. 
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UNIVERSITY OF ILLINOIS 
AT URBANA-CHAMPAIGN 

Center for Supercomputing Research and 
Development (CSRD) at University of Illinois 
at Urbana-Champaign is seeking: 

Computer Systems Engineers and Senior 
Computer Systems Engineers for work on 
Center’s ongoing multiprocessor system, 
Cedar, Design/debug experience is a must. 
Prefer experience or strong technical interest 
in multiprocessor system design involving in¬ 
terconnection networks, memory systems, 
and/or processors. Expertise in areas of 
multiprocessor cache architecture and 
simulation of complex computer systems 
desired. 

Software Engineers and Senior Software 
Engineers for 1. compiler group which is 
developing state-of-the-art parallelizing com¬ 
piler and restructurers for C, Lisp, and FOR¬ 
TRAN. Prefer formal education and experi¬ 
ence in traditional compiler techniques. 2. 
Experienced Unix Kernel professionals to 
work on multiprocessor extensions to Unix 
for a large, shared memory multiprocessor 
system (Cedar). 3. Professionals to work on 
scientific user environments and perfor¬ 
mance evaluation. 

Computer Scientists and Senior Com¬ 
puter Scientists for developing parallel 
algorithms and using them in a number of 
engineering and scientific applications as well 
as designing and implementing numerical 
algorithms for the Cedar system. 

Seeking additional applicants with degrees 
in Computer Science, Computer Engineer¬ 
ing, Electrical Engineering, or a closely re¬ 
lated rield for following full-time regular posi¬ 
tions; “visiting” titles are full and/or part-time 
temporary positions: 

Ph D. preferred. M.S. degree with 4 years 
experience required. 

SENIOR COMPUTER SYSTEMS ENGI¬ 
NEERS AND VISITING SENIOR COM¬ 
PUTER SYSTEMS ENGINEERS. To pro¬ 
vide expertise and technical leadership in 
development of state-of-the-art multi¬ 
processor architecture and hardware 
SENIOR SOFTWARE ENGINEERS 
AND VISITING SENIOR SOFTWARE 
ENGINEERS. To provide programming ex¬ 
pertise and technical leadership in compiler 
development for parallel and array com¬ 
puters, operating systems implementation, 
and instrumentation of parallel systems for 
performance evaluation. 

Ph.D. preferred. M.S. degree with 2years 
experience required. 

SENIOR COMPUTER SCIENTISTS 
AND VISITING SENIOR COMPUTER 
SCIENTISTS. To provide technical leader¬ 
ship in the development of multiprocessor 
numerical and nonnumerical algorithms in a 
variety of applications, including graphics. 

M.S. or equivalent experience preferred. 
B.S. degree with 2 years experience re¬ 
quired. 

COMPUTER SYSTEMS ENGINEERS 
AND VISITING COMPUTER SYSTEMS 
ENGINEERS. To take part in research and 
development of state-of-the-art multiproces¬ 
sor architecture and hardware. 

SOFTWARE ENGINEERS AND VISIT¬ 
ING SOFTWARE ENGINEERS. To take 
part in research and development of the 
above software activities. 

COMPUTER SCIENTISTS AND VISIT¬ 


ING COMPUTER SCIENTISTS. To pro¬ 
vide programming expertise and take part in 
research and development of the above 
numerical and nonnumerical algorithms 

Send resume to: 

Cathy Warmbier, Center for Supercom¬ 
puting Research and Development, 104 S 
Wright St., 305 Talbot Lab, Urbana, Illinois 
61801 217/244-0056. 

Salaries commensurate with experience. 

Specify position(s) and refer to ad 
1989GEN; otherwise application may be 
delayed. In order to ensure full considera¬ 
tion, submit applications by May 12, 1989. 
Interviews may take place before closing 
date, but no final decisions will be made until 
after closing date. Starting date is flexible. 

The University of Illinois at Urbana- 
Champaign is an Affirmative Action/Equal 
Opportunity Employer. 


SOUTHERN METHODIST UNIVERSITY 

Department of Computer Science 
and Engineering 

The Department of Computer Science 
and Engineering (CSE) invites applications 
for a tenured senior faculty position and 
regular tenure-track or visiting faculty posi¬ 
tions at all ranks. Applicants for the senior 
position should have an outstanding reputa¬ 
tion in academic pursuits and experience in 
leading group research projects. Applicants 
for the regular tenure-track positions should 
have a Ph.D. degree and demonstrated re¬ 
search and teaching experience in computer 
science, or a related area. We are interested 
in applicants in all areas of computer science, 
but especially seek candidates with research 
interests in artificial intelligence, distributed 
processing, parallel algorithms, or systems 
performance evaluation. 

SMU is a private university with approxi¬ 
mately 9,000 students. CSE is in the School 
of Engineering and Applied Science, where 
a close working relationship exists with the 
Departments of Electrical Engineering and 
Operations Research. The Department has 
extensive contacts with computer-related 
and engineering-oriented industrial firms 
that distinguish Dallas as one of the top 
centers for high technology. 

CSE presents a balanced program of 
research and education at all levels and has 
been offering Ph.D. degrees since 1970. 
Our current faculty strength lies in algo¬ 
rithms, computer architecture and parallel 
processing, and knowledge/data base sys¬ 
tems. Departmental computing facilities in¬ 
clude a VAX 11/780, two reconfigurable 
multiprocessor systems using INMOS T414 
transputers, several Sun Workstations, three 
LISP machines, numerous personal com¬ 
puters, graphics equipment, and micropro¬ 
cessor development systems. 

Applicants should send a complete re¬ 
sume, including three references to: 

D.W. Matula, Acting Chairman 
Department of Computer Science and 

Engineering 

Southern Methodist University 
Dallas, Texas 75275-0122 
SMU is an. equal opportunity/affirmative 
action employer. Applications from women 
and minorities are particularly encouraged. 


UNIVERSITY OF MIAMI 
Victor P. Clarke Chair 
in Computer Engineering 

The Department of Electrical and Com¬ 
puter Engineering of the University of Miami 
invites nominations and applications for the 
recently established Victor P. Clarke Chair in 
Computer Engineering. It is expected that 
candidates will have an outstanding reputa¬ 
tion in research, an established record in 
external funding, and a commitment to the 
development of computer engineering 
education in the Department. Preferred 
areas of interests are computer architecture, 
computer graphics, computer networks, 
computer vision, expert systems, parallel 
processing, and real-time systems. Salary 
and other benefits are competitive. 

The Department offers B.S., M.S. and 
Ph.D. programs in Electrical and Computer 
Engineering. Approximately ten of the twen¬ 
ty faculty are in Computer Engineering/Sci¬ 
ence. The University is located in beautiful 
Coral Gables, a suburb of Miami, FL. Nomi¬ 
nations/applications should be sent with the 
names of five references to: Dr. Tzay Y. 
Young, Acting Chair, Department of Elec¬ 
trical and Computer Engineering, P.O. Box 
248294, University of Miami, Coral Gables, 
Florida 33124. The University of Miami is an 
equal opportunity/affirmative action 
employer. 


SYRACUSE UNIVERSITY 
The School of Computer 
and Information Science 

The School of Computer and Information 
Science at Syracuse University expects mul¬ 
tiple openings in all areas of computer sci¬ 
ence at all professional levels. Qualifications 
for the position include a Ph.D. or equivalent 
in Computer Science or a related area and 
evidence of the abilities to conduct scholarly 
research and to develop external funding 
sources. As part of our multi-year recruiting 
plan, we shall emphasize this year the core 
areas of Computer Science (Languages, 
Operating Systems, Software Design) and in 
particular, the subareas that relate to 
massively parallel systems. We shall, how¬ 
ever, consider outstanding candidates in any 

The School of Computer and Information 
Science operates as part of Syracuse Univer¬ 
sity, a moderate-size private university com¬ 
mitted to excellence in both teaching and 
research. We offer modem facilities, com¬ 
petitive compensation, and a congenial at¬ 
mosphere in a scenic, central, and highly af¬ 
fordable part of the country. 

Candidates should submit a statement of 
interest along with three to six names of 
reference (depending upon desired rank) 
and a resume to: 

Faculty Search Committee 
School of Computer and Information 
Science 

Syracuse University 
313 Link Hall 

Syracuse, New York 13244-1240 
Application deadline is May 1, 1989. 
Syracuse University is an Equal Oppor¬ 
tunity Employer. 
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SYSTEMS ENGINEER 

Systems Engineer for firm in SW Ohio to 
provide specialized consultancy on location 
to design, develop and analyze systems ap¬ 
plications software in data-base for UNISYS 
and IBM mainframe computers using CO¬ 
BOL, C, FORTRAN, LISP, GEMCOS, 
ALGOL and SAS languages, using interac¬ 
tive conversion techniques, compiler con¬ 
struction; data communication interface and 
network architecture. Require B.S. in Com¬ 
puter, Information Systems, or Manage¬ 
ment Engineering with 2 years’ experience in 
job described or M.S. in any of these 
disciplines. Extensive travel (75%) to various 
locations (Indianapolis, Columbus, Cleve¬ 
land, Cincinnati) for periods of 3-9 mo. per 
project/assignment (expenses reimbursed). 
40 hrs/wk, 8:30am-5pm. $640/wk. Quali¬ 
fied applicants reply immediately with 
resume to R. Lechler, J0*1170804, Ohio 
Bureau of Employment Services, P.O. Box 
1618, Columbus, OH 43216. 


CARNEGIE MELLON UNIVERSITY 
Robotics Ph.D. Program 
Faculty Positions in Robotics 

Applications are invited for tenure-track 
faculty positions in the Robotics Ph.D. Pro¬ 
gram at Carnegie Mellon University. The 
program is interdisciplinary with participation 
from the Robotics Institute, School of Com¬ 
puter Science, Carnegie Institute of Technol¬ 
ogy (the engineering college), and Graduate 
School of Industrial Administration. Ap¬ 
pointees are expected to play major roles in 
education and research in the program. The 
appointments may be made at either assis¬ 
tant, associate, or full professor levels, and in 
general will be joint positions between the 
Robotics Institute and an academic depart¬ 
ment or school, depending on the qualifica¬ 
tions and backgrounds of the applicants. If so 
desired, a non-tenure-track research faculty 
position at the Robotics Institute can also be 
considered. 

Applicants for tenured positions must 
have strong records of achievements in re¬ 
search and education in robotics and have 
demonstrated leadership in formulating and 
performing advanced research projects. Ap¬ 
plicants for junior tenure-track positions must 
have a Ph.D. in a related discipline arid have 
demonstrated competence in one or several 
areas of Robotics research together with 
potential for excellent teaching. 

Outstanding candidates in all areas of 
Robotics are invited, including, but not 
limited to, mechanism, manipulation, con¬ 
trol, locomotion, vision, design, planning, 
knowledge-based systems, simulation, 
graphics, micro-electronics, parallel com¬ 
puting, manufacturing, and management. 

Applicants should send their application 
with curriculum vitae and names of at least 
four references to: Professor Takeo Kanade, 
Director of the Robotics Ph.D. Program, The 
Robotics Institute, Carnegie Mellon Universi¬ 
ty, Pittsburgh, PA 15213. 

Carnegie Mellon is an Equal Opportunity/ 
Affirmative Action employer. 


UNIVERSITE CATHOLIQUE 
DE LOUVAIN 
Belgium 

Department of Computer Science 
and Engineering 

The Universite Catholique de Louvain in¬ 
vites applications for a faculty position in the 
Department of Computer Science and Engi¬ 
neering to be filled by October 1,1989. Rank 
and salary depend upon qualifications and 
experience. Responsibilities include re¬ 
search, supervision of graduate student 
research, participation in the management of 
research projects, graduate and undergradu¬ 
ate teaching. Candidates should have a 
Ph.D. in computer science and/or engineer¬ 
ing and a commitment to excellence in both 
research and teaching; leadership skills are 
highly valued. A working knowledge of the 
French language is expected. All areas of 
specialization in computer science/engineer¬ 
ing will be considered, with some preference 
given to topics of current interest in the 
department: software engineering, artificial 
intelligence, distributed and parallel systems, 
foundations of computer science. 

The department belongs to the School of 
Engineering; it is located in the new city of 
Louvain-la-Neuve, 30 km. south of Brus¬ 
sels, the capital of Belgium, in the heart of 
Europe. 

Additional information about the position 
may be obtained from Prof. E. Milgrom, 
President du Departement GIMA, Place 
Sainte-Barbe, 2, B-1348Louvain-la-Neuve, 
Belgium (Tel: +32 10 47 31 50, Fax: +32 
10 45 03 45, E-mail: em@lln-cs.UUCP, 
em@info.ucl.ac.be). 

A resume (including full bibliography), a 
certified copy of the degree, one copy of the 
five most significant publications, a research 
plan for the next three years and the names 
of three references should be sent before 
May 15, 1989 to: Prof. P. Macq, Recteur 
UCL, Place de l’Universite, l.B-1348 Lou¬ 
vain-la-Neuve, Belgium. 


SWISS FEDERAL INSTITUTE 
OF TECHNOLOGY, ZURICH (ETH) 
Head of Research Group 

Applications are invited for the position of 
Research Group leader. Applicants at Ph.D. 
level should be qualified to guide the 
research efforts of a team of 6 to 8 computer 
scientists and EEs engaged in building a 
coarse-grain data flow multiprocessor and its 
associated software development environ¬ 
ment (using a functional and object oriented 
language). This project is supported by the 
Swiss Science Foundation, and excellent 
computer support is available. It is expected 
that candidates will have thorough experi¬ 
ence in computer architecture and/or com¬ 
pilers; alternatively, know-how in the area of 
advanced CAD for electronic system devel¬ 
opment is also welcomed. No German re¬ 
quired; however, willingness to acquire a 
working knowledge is welcomed. Possibility 
to apply for vacant faculty positions. A de¬ 
tailed resume with 4 references should be 
sent to Prof. Albert KUndig, Institut fur 
Elektronik, ETH-Zentrum, CH-8092Zurich, 
Switzerland (E-Mail: kuendig@nimbus.ethz. 
ch/FAX: +41-1-251-2172). 


GETTYSBURG COLLEGE 
Associate Provost 
Responsible for Computing 

Gettysburg College seeks an energetic 
academic administrator or faculty member to 
assume a newly created Associate Provost 
position. The successful candidate will have 
direct responsibility for Academic Compu¬ 
ting, Administrative Computing, and Tele¬ 
communications; he or she will also assist the 
Provost in overseeing programs in Compu¬ 
ter Science, Mathematics, Biology, Chemis¬ 
try, and Physics. 

The successful candidate will have either a 
Doctorate in Computer Science, Informa¬ 
tion Systems, or a related field, or a Ph.D. in 
Mathematics or one of the Natural Sciences 
and a Masters Degree or equivalent in a 
computing field. Salary commensurate with 
experience and qualifications. 

Gettysburg College is a highly selective 
liberal arts college. It is an affirmative ac¬ 
tion/equal opportunity employer; women 
and minorities are encouraged to apply. 
Historic Gettysburg is within easy driving 
distance of Baltimore and Washington. In¬ 
terested persons should send application 
and resume, including the names of three 
references, by April 21 to L. Baird Tipson, 
Provost, Gettysburg College, Gettysburg, 
PA 17325-1486. 


COMPUTER SYSTEMS ANALYST 

Min. 1 year experience with BS degree 
computer science or will accept with 2 years 
experience with BS degree any other profes¬ 
sional field. Prior experience must also in¬ 
clude work with COBOL and that as a pro¬ 
gramme analyst. Will conduct logical 
analyses of technical problems and business 
procedures using the advanced techniques 
of systems analyses and formulate models of 
problems for solutions by computer in con¬ 
nection with our retail merchandising. Salary 
$42800 yr. Send resume to Bargain Whole¬ 
sale, 3751 Jewel Ave., Vernon, CA 90058. 
Attn: Carlos Lopez. 


SYSTEMS ENGINEER 

Systems Engineer for consulting firm in 
Cincinnati, Ohio, to design and develop 
systems/software for Computer Integrated 
Mfg. (CIM) applications; design, develop 
and implement automated mfg process and 
automatic control machinery projects; apply 
Artificial Intelligence/Expert Systems knowl¬ 
edge for advanced development in CIM en¬ 
vironments; assess state-of-the-art technol¬ 
ogies in Robotics, Artificial Intelligence, 
Computer Architecture, CAD/CAM, and 
related disciplines for mfg applications. No 
experience required in job described but ap¬ 
plicants will qualify with the following: M.S. 
Mechanical Engineering; 1 graduate course 
each in Robotics, Artificial Intelligence, 
Computer Architecture, and CAD/CAM; 
and 6 months research engineering ex¬ 
perience. 40 hrs/wk, 8am-4:45pm. $630/ 
wk. Qualified applicants reply immediately 
with resume to R. Lechler, JO* 1099624, 
Ohio Bureau of Employment Services, P.O. 
Box 1618, Columbus, OH 43216. 
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RENSSELAER POLYTECHNIC 
INSTITUTE 

The Computer Science Department in¬ 
vites applications for tenure-track faculty 
positions at all academic ranks. Research, 
visiting and postdoctoral appointments may 
also be available. Applicants should have a 
Ph.D. in Computer Science (or a related 
area) and a commitment to excellence in 
teaching and research. Preferred research 
interests are parallel computation, database 
systems, computer graphics, computer vi¬ 
sion, image processing, VLSI systems and 
symbolic computation; however, all areas 
will be considered. The department offers 
B.S., M.S., and Ph.D. degrees in Computer 
Science and has excellent computing facili¬ 
ties. Send resumes and at least three refer¬ 
ences to Joseph E. Flaherty* Chairman, De¬ 
partment of Computer Science, Rensselaer 
Polytechnic Institute, Troy, New York 
12180-3590. Rensselaer is an Equal Oppor¬ 
tunity/Affirmative Action Employer. 


THE GEORGE WASHINGTON 
UNIVERSITY 

Computer Science Faculty Positions 

Computer Science faculty positions at the 
Assistant, Associate and Full Professor ranks 
ate available commencing Fall Semester 
1989. 

Especially sought are applicants able to 
conduct research and teach in the areas of 
image processing, machine vision, artificial 
intelligence artd interactive computer graph¬ 
ics. Candidates should have an earned Doc¬ 
torate and research experience with an in¬ 
terest in both teaching and research. Ability 
to attract funded research is valued. The 
George Washington University is located in 
the center of Washington, DC. This metro¬ 
politan area sustains the second largest 
concentration of research and development 
activity in the United States, creating a con¬ 
tinuing demand for rigorously-trained engi¬ 
neers and many research opportunities. Our 
Department is the largest in the School of 
Engineering & Applied Science with 38 full¬ 
time faculty, accredited electrical engineer¬ 
ing, computer engineering, and computer 
science degree programs, a large graduate 
and undergraduate student body, and a sub¬ 
stantial research budget. Current funded 
research projects include computer graphics, 
computer security, data transmission stan¬ 
dards and compression, fast packet switch¬ 
ing, image processing, intelligent user inter¬ 
faces, laser shields, MHD plants, magnetic 
devices, medical imaging, multipath fading 
and encryption, remote sensing, space- 
based radar, and special-purpose VLSI 
designs. Send curriculum vita, list of publica¬ 
tions and 3 references to: 

Professor James D. Foley, Chairman 
Department of Electrical Engineering 
& Computer Science 
School of Engineering & Applied Science 
The George Washington University 
Washington, DC 20052 
The George Washington University is an 
equal opportunity/affirmative action 
employer. 


YALE UNIVERSITY 
Director 

Science and Engineering 
Computing Facility 

Yale University invites applications from 
individuals with experience supporting the 
use of distributed computers in a forefront 
academic institution. The Director will super¬ 
vise a small staff of technical personnel and 
will provide technical advice and assistance 
to the faculty in the science and engineering 
departments and to the Office of the Provost 
on the instructional and research applica¬ 
tions of the full range of computers (micros to 
supers). The Director also represents the in¬ 
terests of bur scientific computing communi¬ 
ty with vendors and with various consortia 
(e.g., DECUS, Apple University Consor¬ 
tium, the national supercomputer centers). 
Applicants should have a doctoral degree or 
equivalent in some field of science or engi¬ 
neering. The possibility exists for combining 
this position with a teaching or research ap¬ 
pointment in the science or engineering 
department that corresponds most directly 
with the candidate’s interests. Review of can¬ 
didates will begin upon receipt of applica¬ 
tions or nominations. To be considered ap¬ 
plications must be received by May 1st. Send 
resume with the names of three references to 
Prof. R. Apfel, Chair, SECF Search Com¬ 
mittee, Council of Engineering, P.O. Box 
1968 Yale Station, Yale University, New 
Haven, CT 06520. Yale University is an af¬ 
firmative action, equal opportunity employer 
and encourages applications from members 
of minority groups. 


WRIGHT STATE UNIVERSITY 
Department of Computer Science 
and Engineering 
Dayton, OH 45435 

Applicants are invited for tenure-track and 
visiting faculty positions at all levels. Suc¬ 
cessful candidates for tenure-track positions 
should have a Ph.D. in computer science, 
computer engineering, or equivalent back¬ 
ground and have demonstrated forward 
looking and creative research. Further 
desired attributes include: capability to direct 
Ph.D. candidates in computer science or 
computer engineering and the ability to ac¬ 
quire funds and/or direct research projects. 
All technical areas will be considered, but AI- 
related areas including machine learning and 
neural networks are of particular interest. 
Other areas of interest are operating sys¬ 
tems, programming languages, and data¬ 
bases. Rank and competitive salaries are 
determined by qualifications and experience. 

Please submit a detailed resume including 
names of three references to: CSNET ad¬ 
dress: amcaulay@wright.edu or Alastair D. 
McAulay, NCR Distinguished Professor and 
Chair, Department of Computer Science 
and Engineering, Wright State University, 
Dayton, OH 45435. Reviewing for positions 
will begin immediately and continue monthly 
until positions are filled or until September 1. 

An equal opportunity/affirmative action 
employer. 


ROYAL MILITARY COLLEGE 
Tenure-Track Position, 

Computer or Electrical Engineering 

Tenure-track position, effective 1 July 
1989; rank of Assistant Professor, Depart¬ 
ment of Electrical and Computer Engineer¬ 
ing. Ph.D. required; knowledge of French 
essential. (Candidates near completion of 
Ph.D. will be considered at Lecturer level.) 
Industrial experience an asset. Responsibili¬ 
ties include teaching, supervision of graduate 
students, and research, with preference for 
computer engineering or electrical power. 
Salary scales competitive. Submit applica¬ 
tion, in writing, with CV, names and ad¬ 
dresses of 3 references to: Dr. M.B. Brough¬ 
ton, Head, Department of Electrical and 
Computer Engineering, Royal Military Col¬ 
lege of Canada, Kingston, Ontario, K7K 
5L0, Canada. Deadline for applications: 10 
May 1989. 

The Royal Military College is a coeduca¬ 
tional institution and this position is offered 
equally to men and women. In compliance 
with Canadian immigration policies, this ad 
is directed to citizens, permanent residents, 
and landed immigrants of Canada. 


SYSTEM SPECIFICATION AND 
DESIGN METHODS ANALYST 

As part of an interdisciplinary team, use 
theories of human cognitive capacities and 
comprehension to invent techniques for 
eliciting, formalizing, and analyzing the re¬ 
quirements of eventual users of large, com¬ 
plex software-controlled systems (e.g., air 
traffic control and telecommunications) and 
for describing these requirements to the 
designers of such systems; formulate re¬ 
search projects in requirements analysis, for¬ 
mal specification, and theoretical models of 
the software development process with the 
goal of improving system specification and 
design practices; develop theoretical models 
of the incremental formalization of software 
specifications; implement prototype soft¬ 
ware tools based on the theoretical models; 
conduct evaluative studies to test the effec¬ 
tiveness of specification; and design meth¬ 
ods, languages, and tools. Have one year’s 
experience in industrial use of formal specifi¬ 
cation and design methods; have one year’s 
experience in the following specification and 
design methods; JSD, Structured Analysis, 
and either CORE or SADT; have two years’ 
experience in planning, conducting, and 
analyzing empirical studies of human 
behavior; during last five years, have pre¬ 
sented at conferences or had published in 
the professional literature at least five 
refereed papers about formal specification, 
design methods, or software process model¬ 
ing. Applicants must possess Ph.D. in either 
Psychology or Computer Science as well as 
four years’ experience as System Specifica¬ 
tion and Design Methods Analyst and one 
and one-half years’ experience as Systems 
Analyst. $57,500/year; 40 hours/week. 
Apply at the Texas Employment Commis¬ 
sion, Austin, Texas, or send resume to the 
Texas Employment Commission, TEC Build¬ 
ing, Austin, Texas 78778, J.O.* 5515289. 
Ad paid by an Equal Employment Oppor¬ 
tunity Employer. 
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HARVEY MUDD COLLEGE 
Position Announcement in Computer 

Applications are invited for a one-year 
visiting position in Computer Science begin¬ 
ning July 1, 1989. An applicant should 
have, or be close to completion of, a Ph.D. 
in Computer Science and have a strong in¬ 
terest in both undergraduate teaching and 
research. Candidates from all areas of com¬ 
puter science or a computer-related field will 
be considered. Responsibilities include 
teaching, research, and the supervision of 
industrially-sponsored projects in computer 
science. The Computer Science Department’s 
facilities include a network composed of a 
VAX 11/750 and a Sequent Symmetry. 
The Computer Science network is also in- 
terefaced with the college network of VMS 
machines: a Micro VAX 2, 4 VAX ll/750s, 
and a VAX 8600. 

Harvey Mudd College, one of the nation’s 
most selective undergraduate colleges, is a 
member of The Claremont Colleges. The 
College is an equal opportunity/affirmative 
action employer. Please send resume and 
the names of four references to Professor 
Wing C. Tam, Computer Science Depart¬ 
ment, Harvey Mudd College, Claremont, 
CA 91711. 


Rochester Institute of Technology 
School of Computer Science 

Department of Applied Computer 
Studies 

Software Engineering Position 

Visiting or Tenure Track faculty position 
available for individual who has experience 
in the instruction of Software Engineering 
topics, both managerial and technical. Ph.D. 
or Master’s (with professional experience) 
degree in appropriate discipline required. 
Duties will include teaching at the graduate 
level (M.S.) as well as applied research in 
Software Engineering. 

Send resume to Prof. Guy Johnson, De¬ 
partment of Applied Computer Studies, 
1 Lomb Memorial Drive, RIT, Rochester, 
New York, 14623. RIT is an equal oppor¬ 
tunity affirmative action employer. 


CHAPMAN COLLEGE 
Computer Science and Mathematics 

Chapman College seeks applications for 
tenure-track position as Assistant Professor 
of Mathematics and Computer Science be¬ 
ginning Fall, 1989. Teach undergraduate 
course in computer science and mathema¬ 
tics. Ph.D., outstanding teaching, excellence 
in scholarship, and firm commitment to 
working with students required. Salary is 
commensurate with qualifications and ex¬ 
perience. Chapman College is a small pri¬ 
vate liberal arts/pre-professional college 
located 30 miles south of Los Angeles. Send 
curriculum vita and three letters of reference 
to Gary Ramet, Chair, Math and Computer 
Science Department, Chapman College, 
Orange, CA 92666. Deadline: May 1, 1989. 
Affirmative Action/Equal Opportunity' 
Employer. 


Computer Engineers 

Put your career on-line with GE. 


Our challenge, your opportunity 

GE Aircraft Engines is the international leader in high-performance cost- and fuel- 
efficient engines. Our rapid growth has created 3 exceptional opportunities for 
computer engineers at our manufacturing facility in Cincinnati, OH. You will join 
our pacesetting team developing a state-of-the-art computing system, from desk¬ 
top workstations to supercomputers. 


Senior Staff Engineer 

Will provide program management for all major activities to ensure success of en¬ 
gineering workstation projects. You’ll create new system concepts for major 
product releases; generate solutions to complex problems; and coordinate activi¬ 
ties with assigned personnel. 

Requires demonstrated complex program management skills and the ability to 
assume responsibility for the design/development/deployment of a distributed 
heterogeneous computing environment. 


Planning Systems Engineer 

Will participate in all related activities to ensure successful operation of engineering 
workstation projects. Includes installation of base computing systems; evaluation of 
new concepts; determination of planning approaches; and solution of complex 
problems. 


Software Systems Engineer 

Coordinating with design groups, you will plan, develop and implement activities 
for software development system configuration and administration. Responsible 
for evaluation of new system concepts, solving problems of new derivative sys¬ 
tem and software programming and implementation activities. 

Requires several years experience in software development of UNIX* system 
configuration and administration in a distributed environment using C, window 
manager and network services. 


Your expert credentials 

These positions require a BS in Math, Computer Science or Engineering, 5-10 
years relevant experience with UNIX*, software development, highspeed net¬ 
working and computer system installation. Excellent communication and organi¬ 
zational skills are necessary. An advanced technical or business degree is highly 
desirable. 


Reward your talents 

GE offers competitive salaries, excellent benefits including relocation and home 
sales assistance, and a professional environment with the most advanced comput¬ 
ing technology. Plus you’ll enjoy the advantages of a pleasant urban setting 
known for its relaxed, stable lifestyle. Please send resume with salary history and 
indication of position desired to: Ms. Bernadette A. Rodak, Ref. 11, GE Aircraft 
Engines, Bldg. 800 C-15, Cincinnati, Ohio 45215. 


GE Aircraft Engines 


An Equal Opportunity Employer 
’UNIX is a trademark of AT&T 
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The Second IEEE Symposium on 
Computer-Based /Medical Systems 
June 25-27, 1989 • /Minneapolis, /Minnesota 


► Engineering in /Medicine and Biology 
Society of the IEEE 
) The Computer Society of the IEEE 

UNIVERSITY OF/MINNESOTA 


The Program 

June 26-27, contributed and invited papers will be presented 
in the following areas: 

• Care assessment and risk evaluation • Regulations and standards 

• Artificial intelligence and neural nets • Medical devices 

• Reliability and validity 

The paper selection process has been completed. Authors include 
representatives from industry, academe medicine government, and private 
enterprise Titles selected include "Development of a medical device data 
language standard," "Regulation of expert systems by the FDA'' "A hazard- 
oriented approach to computer system safety," "Detection of ischemic 
responses during treadmill excercise by computer-aided impedence 
cardiography," "Implantable ventricular assist systems," and "A software 
quality assurance procedure to assure a reliable software device." 

Tutorials 

On Sunday, June 25, four concurrent tutorials will be offered from 
1:00-5:00 pm. They are: 

• Reliability and safety 

• FDA regulations and CBMS 

• Neural nets 

• Chronobiology and its applications to CBMS 
Registration for tutorials is limited. 


Who Should Attend 

This conference is intended for engineers and computer scientists from 
industry who are designing and developing Computer-Based Medical 
Systems (CBMS). Reports about applications in progress are encouraged. 
Academic and professional people who wish to discuss and define their 
needs for CBMS or who are working on such systems will also find the Sym¬ 
posium valuable. The Symposium provides an excellent opportunity for 
government regulators to interact with those working in the CBMS area. 
Medical residents and fellows working on computer projects and advanced 
engineering and computer science students working on medical projects 
are especially encouraged to attend. 


Information 

Content questions should be directed to Dr. Kriewall. All other cor¬ 
respondence should be directed to Dr. Bart Galle at: Continuing Medical 
Education, University of Minnesota, Box 202 UMHC, 420 Delaware Street 
S.E., Minneapolis, MN 55455, USA, (612)626-5525 


Symposium Committee 

PROGR4VI CH4IRT44N 

Timothy J. Kriewall, Ph.Di 

Sarns, lnc/3M 
6200 Jackson Rd. 

Ann Arbor, Ml 48103 USA 
(313)663-4145 

TRACK CHAIRV1EN 

Richard Fries 

Nicolet Instruments 
Madison, Wl 

Stephen R. Quint, Ph.Q 

Biomedical Engineering 
University of North Carolina 
Chapil Hill, NC 

Peter Thorp 

SERC/3M Company 
St. Paul, MN 

George Wilcox, Ph.Di 

Pharmacology 
University of Minnesota 
Minneapolis, MN 

COOPERATING ORGANIZATIONS 

Region 7 IEEE 

Twin Cities Chapters of CS, EAABS 
IEEE CS Technical Committee on 
Computational /Hedicine 

For/More Information 
or to Register 

Call or Write the 

Office of 

Continuing Medical Education 
University of Minnesota 
Box 202 UMHC 
420 Delaware Street S.E. 
Minneapolis, MN 55455 USA 
Telephone (612)626-5525 


tu Host Cities 

Qnd Stl ft ? ul ?. rea '5 h ° m< l for s « veral hundred medical high-tech companies, almost all of which have 
i conn P uter -, based - The Twin Cities of/Minneapolis and St. Paul are also rich in culture and heritage 
/Minneapolis, has long been known as the City of Lakes. St. Paul is the seat of/Minnesota's state government. 

iT?982 The^o^i^om^ £ downtown/Minneapolis with the completion of the Hubert H. Humphrey/Metrodome 
the!Snne1ota Twfns h * the /Minnesota Vikings football team and the 1987 World Series Baseball Champions. 

*5“ interests include the nationally recognized/Minnesota Orchestra, St. Paul Chamber Orchestra, and the Guthrie 
Th«^'rf S , ^ as th f technoioQically-advanced Science/Museum of/Minnesota / William L./McKnight-34A Omnitheater. 
There are other acclaimed museums including the/Minneapolis Institute, the Walker and the new Sculpture Garden. 










BOOK REVIEWS 


Editor: Wiley McKinzie, School of Computer Science and Technology, Rochester Institute of Technology, Rochester, NY 14623; Compmail, w.mckinzie; CSnet, wrm@ rit 


CASE: Using Software Development Tools 

Alan S. Fisher (John Wiley & Sons, New York, 1988, 287 pp„ $24.95) 


This book offers a highly readable but 
somewhat shallow overview of the most 
popular commercial computer-aided soft¬ 
ware engineering tools and their method¬ 
ologies. It fills a gap as a general text on 
commercial CASE tools and methodolo¬ 
gies without noticeable bias toward any 
particular vendor. It targets practicing 
software engineers and managers who 
need a quick overview of the subject but 
are not now willing to thoroughly inves¬ 
tigate it. 

Each of the book’s four parts ad¬ 
dresses a slightly different audience. Part 
1 attempts to justify CASE tools and 
presents a fairly good account of the tra¬ 
ditional waterfall model of software de¬ 
velopment and the tools commonly used 
in each phase. Noting that errors found 
in requirements analysis and design 
specification are much easier to correct 
than errors found later in the software 
development cycle, the author defines 
computer-aided software engineering as 
the use of “tools that provide leverage in 
the software project requirements analy¬ 
sis and design specification phases, and 
those tools which, potentially, generate 
code automatically from the software de¬ 
sign specification.” The author thus in¬ 
cludes special-purpose code generators 
in his definition of CASE tools, but 
excludes project management tools, con¬ 
figuration management tools, code ana¬ 
lyzers, code restructuring tools, perform¬ 
ance analyzers, and the like. 

The author states a preference for the 
cyclic model of software development, 
but in Part 2 describes only methodolo¬ 
gies designed for the waterfall/phased 
model, such as Yourdon/DeMarco struc¬ 
tured analysis (dataflow diagrams, data 
dictionaries, minispecifications, structure 
charts) and its variations. Data-modeling 
methodologies and user-interface design 
methodologies are also briefly covered. 
The author fails to address issues such as 
software reuse, evolutionary delivery, at¬ 
tribute specification, and the use of met- 

Part 3 offers an overview of 10 se¬ 


lected commercial CASE tools, witn an 
ample number of black-and-white screen 
shots to give a feel for the tools de¬ 
scribed. Five of the tools apply the Your¬ 
don/DeMarco methodology with varying 
extensions, such as state diagrams for 
real-time analysis, data-modeling meth¬ 
odologies, varying (limited) degrees of 
code generation, and screen design facili¬ 
ties. Two tools represent specialized 
methodologies for data modeling and 
real-time control design. The other three 
are user-interface design tools. The de¬ 
scriptions are fairly detailed and useful. I 
would have liked to see an overview of 
other tools that fit the author’s definition 
of CASE, such as selected code-generat¬ 
ing expert-system design tools and other 
specialized code generators. However, 
the author’s concentration on user-inter¬ 
face code generators is justified by their 
wide appeal. 

Part 4 gives advice on selecting a 
CASE tool and introducing a new meth¬ 
odology into a working environment. It 
also offers the author’s ideas on the fu¬ 
ture of CASE. The author states that 
CASE will never reach its full potential 
without further development toward 


For those who may not know, “struc¬ 
tured analysis” is the horrid buzzword 
that denotes what otherwise might be 
called “specification in parts.” Instead of 
writing a single, monolithic specification 
for a whole application, you first divide 
it into parts, using a dataflow graphic to 
effect your partitioning, and then specify 
the components. If the components are 
still awkwardly large, you can partition 
them first into their components with a 
subsequent (lower level) dataflow. The 
specification of the whole is then the set 
of specifications of the elemental pieces, 


automatic code generation. He does not 
foresee the many developments cited, for 
example, in recent issues of Computer, 
IEEE Software, and IEEE Expert on AI/ 
software engineering. Other issues 
missed here are covered in books such as 
Principles of Software Engineering Man¬ 
agement by Tom Gilb and Susannah 
Finzi (Addison-Wesley, 1988) and Ob¬ 
ject-Oriented Software Construction by 
Bertrand Meyer (Prentice Hall, 1988). 

The book’s appendixes contain ad¬ 
dresses of some 50 tool vendors, training 
organizations, CASE-related confer¬ 
ences, publications, and a list of the rele¬ 
vant DoD standards. The bibliography 
covers the tool categories presented in 
the book. 

The CASE tool (and literature) market 
seems to be going strong due to in¬ 
creased demand, while the tools them¬ 
selves have yet to mature. As the author 
quotes Clint Eastwood in A Fistful of 
Dollars: “When there are two bosses in 
town, there’s money to be made!” 

Nouri M. Allahwerdi 

Kone Instruments 

Espoo, Finland 


together with the diagrams that show 
how the whole is made of its parts. 

Also for those who may not know, 
Edward Yourdon is a lecturer, a prolific 
writer, and a popularizer of all things 
structured. I use the term “popularizer” 
to describe the important and honorable 
role of making good ideas accessible. In 
an interview after his televised series 
Meeting of Minds, Steve Allen said: 

One of the stupidest forms of criticism in¬ 
volves attacking the popularizers of sci¬ 
ence. We must encourage the popularizers, 
because many of the scientists themselves 


Modern Structured Analysis 

Edward Yourdon (Prentice Hall, Englewood Cliffs, N.J., 1989, 672 pp„ $34) 
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are poor teachers, and even those who are 
great teachers are so busy doing their work 
that they don’t have time to teach. 

That is true of science in general, and 
particularly true of computer science. 

The term still has an unfortunate con¬ 
notation. To say that one is a popularizer 
implies that he or she is not a contribu¬ 
tor. In Ed Yourdon’s case, this is espe¬ 
cially unfair. Those who have worked 
with him know that he has consistently 
contributed to our field. He has improved 
the base of ideas covered by his spoken 
and written works. His most significant 
contributions have been in design and 
analysis and in the synthesis of diverse 
techniques into a meaningful discipline 
of development. 

Before reviewing Modern Structured 
Analysis, I must mention that I come to 
the task burdened by a few biases: The 
author is a friend and an off-and-on col¬ 
laborator since the late 1960s. I know 
him to be a kind and generous man; one 
who, in particular, seems never to have 
missed a chance to say a good word 
about me or my work. So, I am quite in¬ 
capable of writing an entirely negative 
review of his book. 

On the other hand (business is busi¬ 
ness), his latest work is in direct compe¬ 
tition with my own Prentice Hall analysis 
book. Think of each copy of Modern 
Structured Analysis sold as a royalty di¬ 
verted from my personal retirement fund, 
monies earmarked for the purchase of 
those little cans of dog food with which 
we must eke out our final days as senior 
citizens. Perhaps these offsetting biases 
will allow me to write a balanced review. 

The good news is that this book, like 
all the author’s prior efforts, is readable, 
entertaining, and insightful. Yourdon has 
a gift of clear prose; you never puzzle 


over what he meant to say. The organiza¬ 
tion is straightforward and sensible. He 
presents the material with a puppy-like 
enthusiasm that is positively infectious. 
When you’re done, you understand the 
subject and you’ve learned amusing and 
often relevant facts from dozens of other 


It is fortunate that the 
digressions are 
interesting, because there 
are lots of them. 


subjects. You also feel that you would 
like to get to know the author, whose 
personality is evident on every page. 

The strongest element of the book is 
oddly disconnected from its subject. 

Over the years, the author has developed 
an original and highly informed perspec¬ 
tive on the computer industry. This per¬ 
spective is most profitably exposed when 
Yourdon digresses onto the topics of re¬ 
liability, military contracting, hardware 
trends, living systems, knowledge engi¬ 
neering, the effects of computing on ado¬ 
lescents, and the like. 

It is fortunate that the digressions are 
interesting, because there are lots of 
them. Without digressions, the book 
might have been limited to 200 pages. 

But the length of the book is one of its 
flaws. At 672 pages, it is not just fat, but 
obese. To make matters worse, the work 
is targeted for the university market, so 
its great length translates into excessive 
cost and reading time for an audience 
that is short on both time and money. An 


elaborately annotated taxonomy of input 
and output devices (Chapter 21) or com¬ 
ments on ex-programmers being elected 
to Congress (Chapter 25) might be in¬ 
triguing, but if I were a student in a uni¬ 
versity analysis sequence, I would con¬ 
stantly wonder whether the maddeningly 
off-the-subject material could ever legiti¬ 
mately end up on a quiz. 

Part of the reason for the excessive 
length of this and other Yourdon offer¬ 
ings is the author’s extraordinary facility 
in writing. I have been with Ed Yourdon 
when he is composing, and can report 
that the process is daunting indeed. He 
spews out polished first drafts, virtually 
at typing speed. (And he types faster 
than anyone else I know.) The drafts are 
good enough to be published, and some 
of them have been. His useful book on 
walkthroughs and inspections, for ex¬ 
ample, is the product of a weekend’s ef¬ 
fort, including typesetting. 

But, if the first draft is his great 
strength, revision is his weakness. When 
he takes more time to write, the work 
just gets longer. He doesn’t seem to be 
able to cut. The saddest victim of this ef¬ 
fect is his best book: Nations at Risk 
(Prentice Hall, 1986). That fascinating 
work is marred by the self-indulgent ver¬ 
bosity that obscured its value and caused 
the book to go largely unnoticed. It is a 
600-page monster with a meaningful and 
important 200-page book trapped inside. 

Modern Structured Analysis suffers 
from the same problem. The book is too 
long and a bit self-indulgent, but still 
valuable. It is part of an increasingly im¬ 
pressive body of work from one of our 
industry’s most articulate commentators. 

Tom DeMarco 

Atlantic Systems Guild 


Internetworking with TCP/IP: Principles, Protocols, 
and Architecture 

Douglas E. Comer (Prentice Hall, Englewood Cliffs, N.J., 1988, 382 pp„ $28.50) 


John Donne said, “No man is an is¬ 
land”; these days, it seems no computer 
is one, either. Computers are connected 
in networks that range from simple local- 
area networks providing print servers for 
personal computers to national and inter¬ 
national networks containing hundreds 
and thousands of computers. 

The growth of these networks has 
made the problem of interconnecting 
them one of great importance. Some of 
the original work on internetworking 
came out of the development of Arpanet 
and research sponsored by the US De¬ 
fense Dept.’s Advanced Research Proj¬ 


ects Agency (DARPA), which led to the 
development of the transmission-control 
protocol/Intemet protocol (TCP/IP). 
DARPA also made the inspired decision 
to develop a low-cost implementation of 
TCP/IP to encourage use by university 
researchers. This led to the implementa¬ 
tion of the Internet protocol under Unix 
by Bolt, Beranek, and Newman, Inc., and 
its inclusion in the University of Califor¬ 
nia at Berkeley’s Software Distribution 
of Unix. This widespread distribution in¬ 
creased the protocol’s popularity and use 
in other networks, such as Ethernet. Its 
popularity has grown so much that, to¬ 


day, everyone uses TCP/IP, but rela¬ 
tively few people know what it really 
consists of. Comer provides a way to fill 
that gap with this book, whose subtitle. 
Principle, Protocols, and Architecture, 
conveys the scope of what he sets out to 
cover. 

The purpose of this book is to provide 
an introductory mechanism to learn 
about TCP/IP. Comer meets this purpose 
admirably. The book is divided into 20 
chapters, averaging less than 15 pages 
each. This allows each chapter to cover a 
small topic and explain it clearly without 
going overboard or presenting extrane- 
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ous material. Each chapter concludes 
with a summary, a list of references for 
further investigation, and a set of exer¬ 
cises that make the book appropriate for 
an advanced computer-networking class. 
In addition, Comer emphasizes important 
points with italic type to make them eas¬ 
ier to pick up. 

The book takes a bottom-up approach 
to explaining the protocols. Comer starts 
by reviewing the whole concept of net¬ 
working and the underlying technologies, 
leading to a discussion of why Internet is 
necessary. This gives a good introduc¬ 
tory basis for the rest of the book. 

Comer next examines the structure of 
internetwork addresses and the various 
protocols that handle logical machine 
names and conversion into physical ad¬ 
dresses that can be used to send mes¬ 
sages. Comer also describes the start-up 
problem of how a machine figures out 
who it is and who it is attached to when 
it is first booted. 

The next set of chapters discusses the 
Internet protocol itself, including the 
underlying concept of connectionless de¬ 
livery, the routing mechanisms used by 
the IP datagrams, and the handling of er¬ 
ror and control messages. 

After covering low-level machine-to- 
machine communications. Comer covers 
the two major protocols for user-level 
communication: user-datagram protocol 
(UDP) for connectionless, datagram 
services, and TCP for reliable, end-to- 
end stream transmission for users. 

The next two sections discuss various 
aspects of internetworking. The first sec¬ 
tion explores gateways, describing the 
concepts of core and noncore gateways 
and the problems involved, including au¬ 
tonomous systems, the need to decentral¬ 
ize Internet, and the need to remove de¬ 
pendencies on the core gateways. The 
second section discusses subnets, which 
let many physical networks share the 
same Internet address. 

The last section of the book covers 
user services provided by Internet, such 
as file transmission, remote terminal 
emulation, remote login, and mail trans¬ 
fer. It also discusses the whole (user- 
visible) naming scheme, along with the 
problems of generating unique names for 
a system the size of Internet and deter¬ 
mining where the authority for name 
generation lies. 

The five appendixes alone are almost 
worth the price of the book. The first de¬ 
scribes the 4.3BSD Unix interfaces to the 
Internet protocol, bringing the earlier 
theoretical discussions down to a practi¬ 
cal level. The next appendix offers gen¬ 
eral hints on bringing the Internet proto¬ 
cols up on a system for the first time. 

The third appendix covers the request for 
comments, the Internet library containing 


most of the information about Internet 
and how it evolved. The last two appen¬ 
dixes consist of a glossary of terms and 
acronyms used in the book and a list of 
all the DARPA-Internet protocols. 

The book is a wonderful reference tool 
about TCP/IP and Internet. Anyone need¬ 
ing information will find an introduction 
here as well as pointers to other available 


information. The book is not so detailed 
that a reader can implement Internet 
protocols directly after reading it, but 
someone trying to do so is well advised 
to have this book available. The book is 
well written, and I highly recommend it. 

Lome H. Schachter 

Bell Communications Research 


The New DOS 4.0 

Ken W. Christopher, Jr., Barry A. Feigenbaum, and Shon O. Saliga (John Wiley & 
Sons, New York, 1989, 515 pp„ $22.95) 


Prior to IBM’s entering the PC mar¬ 
ketplace, the company’s manuals epito¬ 
mized everything that could possibly be 
bad about technical documentation. 
IBM’s first PC manuals, however, set a 
new standard — a standard that fortu¬ 
nately is now reflected in mainframe 
product documentation. That’s not to say 
that all IBM manuals are not arcane. But 
in many ways those sometimes impene¬ 
trable manuals merely reflect the nature 
of IBM products. 


The New DOS 4.0 
probably reflects the way 
the system architects 
wished the documentation 
had been produced. 


For most new computer users, DOS is 
a mysterious barrier to computer literacy 
and productivity. DOS 4.0 attempts to 
unravel some of the mystery for both 
novice and vintage PC users. IBM has 
accomplished this in two ways — via the 
product itself and via the accompanying 
manuals. 

In terms of the product, DOS 4.0 now 
contains an interface called the DOS 
Shell. New users can execute DOS func¬ 
tions by selecting icons with or without a 
mouse. Old hands can continue to use the 
familiar DOS command interface. 

DOS 4.0 is shipped with two manuals 
— Getting Started with Disk Operating 
System Version 4.00 and Using Disk Op¬ 
erating System Version 4.00. While IBM 
still might have some distance to go in 
learning how to give its manuals jazzy 
names, both manuals are very good 
sources of information on DOS 4.00 (it’s 
really DOS 4.01, but IBM doesn’t ac¬ 
knowledge the patches to correct bugs in 
the first release). For new and jaded PC 


users, the IBM manuals provide excel¬ 
lent detailed information on installation, 
the DOS Shell, and DOS functions. 

Since the manuals are so good, you are 
probably wondering what The New DOS 
offers that the standard manuals omit. In 
a word (or two) — not much. As its 
cover explains, The New DOS was writ¬ 
ten by “the IBM staff members respon¬ 
sible for the contents, architecture and 
design of DOS 4.0.” It even has a fore¬ 
word by Bill Lowe, ex-president of IBM 
Entry Systems Division (and also a re¬ 
cent ex-IBMer). Anyone who has worked 
in IBM development knows that product 
developers rarely have much influence in 
the documentation and packaging of re¬ 
leased products. I suspect that this was 
the case with DOS 4.0. This book proba¬ 
bly reflects the way the system architects 
wished the documentation had been pro¬ 
duced. 

The New DOS covers much of the 
same material as the IBM manuals. Top¬ 
ics include installation, the DOS Shell, 
and basic and advanced DOS concepts, 
commands, and utilities. The book is 
well written, well organized, and con¬ 
tains a good index. 

The authors have written the book for 
novices, but some of the material re¬ 
quires significant expertise to be of 
value. An example is the last chapter, 
“Tuning DOS Storage Use and Perform¬ 
ance,” which is unlikely to be of much 
interest to a novice but should be quite 
useful for advanced PC users. 

If you are the kind of person who 
needs more than one reference to under¬ 
stand a subject, then this text will serve 
your purpose. However, the book is un¬ 
necessary for most purchasers of DOS 
4.0. But, if you find yourself in posses¬ 
sion of an undocumented version of DOS 
4.0 (perhaps the dog ate your manuals!), 
then The New DOS will provide you with 
adequate documentation. 

Sorel Reisman 

California State University, Fullerton 
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Single- and Multiple-Chip Microcomputer Interfacing 

G.J. Lipovski (Prentice Hall, Englewood Cliffs, N.J., 1988, 478 pp„ $40) 


Microprocessors have become an inte¬ 
gral part of a wide variety of electronic 
systems. They are used in embedded ap¬ 
plications ranging from home appliances 
to medical equipment and air-traffic-con¬ 
trol radar. They are also used as the main 
processing element in personal computer 
systems and workstations. Despite this 
proliferation of uses, the skills needed to 
design systems using microprocessors 
have frequently been taught ad hoc. This 
book brings a structured approach to the 
teaching of microprocessor-interfacing 
techniques. 

Written in an easy-to-read, conversa¬ 
tional style, this book updates the au¬ 
thor’s previous book. Microcomputer 
Interfacing: Principles and Practices. It 
is intended as a text for a senior-level de¬ 
sign course that includes a strong labora¬ 
tory component. (The laboratory and in¬ 
structor’s manuals containing solutions 
to the problems were not available for 
this review.) This book would also make 
a good self-study guide for the experi¬ 
enced engineer, especially if the reader 
has access to the appropriate hardware. 

The material is organized into nine 
chapters. The first three chapters offer a 
review of general computer concepts that 
ranges from overly simple to very useful. 
For example, the discussion of von Neu¬ 
mann architectures and programming 
styles seems out of place and too simple 
for a senior-level course, while the dis¬ 
cussions specific to microprocessors are 
relevant and quite helpful. In particular. 
Chapter 3 provides an excellent explana¬ 
tion of the subtleties involved in inter¬ 
facing memory devices and other compo¬ 
nents to the microprocessor’s bus. The 
problem of ensuring that the timing con¬ 
straints of the address and data buses are 
met is explained well, using a memory 
interface as an example. 

The remaining six chapters cover the 
problems involved in interfacing micro¬ 
processors to the outside world. The dis¬ 
cussion of general I/O-related problems 
is quite complete. It compares memory- 
mapped and direct I/O techniques, pre¬ 
sents various polling and interrupt 
schemes, and explains when direct-mem¬ 
ory-access methods might be appropri- 

Two chapters are devoted to a good 
presentation of the problems involved in 
analog interfacing. Both digital-to-ana- 
log and analog-to-digital conversion are 
well explained. In addition, the author 
presents several good techniques for us¬ 
ing counting and timing circuits to 
sample and control the frequency behav¬ 


ior of signals. The final two chapters of 
the book give a nice introduction to the 
complex topics of synchronous and asyn¬ 
chronous communications interfaces and 
the techniques for interfacing to storage 
and display systems. 

Some readers may object to the almost 
exclusive use of the Motorola 6811 
single-chip microprocessor in the ex¬ 
amples. The author’s rationale for ignor¬ 
ing other microprocessors is that this is a 
book on microprocessor interfacing tech¬ 
niques, not comparative microprocessor 
architectures. The relative simplicity and 
flexibility of interfacing to the 6811 
makes it an excellent means of teaching 
some important concepts using experi¬ 
ments that should be interesting to stu¬ 
dents. For example, the author presents a 
simple video-display driver that uses 
four resistors, a single transistor, and the 
6811 programmed to provide the re¬ 
quired timing signals. While the result¬ 
ing display system might not be useful in 
a real application, the techniques could 
be easily transferred to any other micro¬ 
processor a student is likely to encounter. 

Throughout the book, the author em¬ 
phasizes top-down design and trading off 
hardware and software to balance cost 
and performance. While I did not always 
agree with the trade-offs he makes, the 
author does a good job of explaining 


these concepts through a number of real¬ 
istic examples. In addition to these gen¬ 
eral design techniques, he introduces a 
number of useful “tricks of the trade.” 
For instance, he points out that eight-bit 
microprocessors do not have enough 
arithmetic precision for many applica¬ 
tions, and presents some useful routines 
for implementing extended-precision 
arithmetic. 

I found the book’s main weakness to 
be the bibliography. The few references 
provided at the end of each chapter are 
rather limited. Since several topics are 
necessarily mentioned rather briefly in 
the text, more-extensive references 
would be useful for students who want to 
pursue a particular topic in more detail. 
This lack of references is not a serious 
deficiency, however. 

The author has written a thorough, de¬ 
tailed, and technically sound introduction 
to microcomputer interfacing. It presents 
concepts and techniques that every 
microcomputer systems designer should 
know. If you are designing a new course 
on microcomputer interfacing (or updat¬ 
ing an old course), I recommend that you 
consider this book for the course text. 

David J. Lilja 

University of Illinois at Urbana- 

Champaign 


NEW LITERATURE 


History of programming. B. Walraet 
offers a critical history of programming 
in Programming, The Impossible Chal¬ 
lenge (ISBN 0-444-87128-4, 464 pp„ 
$78). Written to give programmers and 
analysts a more pragmatic insight into 
their profession, the book tells why the 
technology evolved as it did and how 
fifth-generation techniques are already 
changing the situation, and asks such 
questions as “Is programming a job for 
human beings?” 

In the United States and Canada, con¬ 
tact Elsevier Science Publishing, PO Box 
882, Madison Square Station, New York, 
NY 10159; elsewhere, contact Elsevier 
Science Publishers, PO Box 211, 1000 
AE Amsterdam, The Netherlands. 

Choosing CASE workbenches. CASE 
Analyst Workbenches: A Detailed Prod¬ 
uct Evaluation (two volumes, 780 pp.. 


£550) by Rosemary Rock-Evans pro¬ 
vides guidelines on choosing, imple¬ 
menting, and using analyst workbenches 
to maximum advantage. It reviews 66 
workbenches and includes tables high¬ 
lighting the available features and con¬ 
ventions. Contact Ovum Ltd., 7 Rath- 
bone St., London W1P 1AF, England. 

Managing software engineering. Au¬ 
thor Fletcher J. Buckley asserts that cur¬ 
rent programming courses do not ade¬ 
quately prepare software engineers for 
large-scale projects, and advocates a 
“project management” method as a more 
complete, efficient, and maintainable 
way of developing commercial systems 
in Implementing Software Engineering 
Practices (ISBN 0-471-63386-0, 256 pp., 
$34.95). Contact John Wiley & Sons, 

605 Third Ave., New York, NY 10158- 
0012. 
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TEACHING SIMULATION ANALYSIS 
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Now for universities 
SIMSCRIPT II.5 with SIMGRAPHICS 


New simulation teaching package--provides animated results 


S IMSCRIPT II.5 gives you a 
compact English-like language. 
The simulation program reads like a 
description of the system under 
study. 

With the new SIMGRAPHICS™ 
enhancement, user data is entered 
through an interactive screen based 
dialog. 

Simulation simplified 

Results are easy to understand- 
an animated picture, histograms, 
pie charts, and plots. 

Because simulation results are 
understood, you can concentrate on 
teaching simulation concepts. 

Your students’ model develop¬ 
ment, checkout, modification, and 
enhancement are greatly simplified. 
Many successful applications 
SIMSCRIPT II.5® is a well 
established, standardized, and 
widely used language with 26 years 
of proven software support. 

Typical applications include: 
engineering, business, manufactur¬ 
ing, communications, logistics, 
transportation, and gaming. 

There is no easier way to teach 
simulation programming. 


Low cost to 
universities 

CACI recognizes the benefits of 
having its state-of-the-art systems 
used by universities. 

For that reason we make the 
SIMSCRIPT II.5 teaching package 
available to universities for only a 
low distribution charge. 

The package includes training, 
support, complete documentation, 
and sample models-everything 
you need to conveniently teach 
simulation analysis. 

Act now—limited offer 

This offer is limited to 1,500 
universities, and 1,273 have 
already signed up. Don’t be 
disappointed-call today. 

For immediate information 

Call Eric Chapman at (619) 
457-9681, FAX (619) 457-1184. In 
the UK, call Richard Eve on (01) 
528-7980. 

With SIMSCRIPT H.5 your 
students get results sooner and the 
results are better understood. 


Rush information on the special 
simulation teaching package for 
universities only. 

Everything you need to teach SIMSCRIPT 
II.5 with SIMGRAPHICS. 

Also send information about: 

□ NETWORK II.5® for teaching 
network analysis-no programming. 

□ COMNET II.5™ for teaching telecom¬ 
munication network analysis--no pro¬ 
gramming. 

□ SIMFACTORY II.5® for teaching 
factory planning-no programming. 







Computer Operating System 


Return to: 

CACI Products Company IEEE c 
3344 North Torrey Pines Court 
La Jolla, California 92037 

Call Eric Chapman at (619) 457-9681. 
FAX (619) 457-1184. 

In the UK: 

CACI Products Division 

Regent House, 89 Kingsway 

London WC2B 6RH, United Kingdom 

Call Richard Eve on (01) 528-7980. 


SIMSCRIPT II.S, SIMANIMATION, NETWORK II.5, 
COMNET II.5, and SIMFACTORY are registered 
trademarks and service marks of CACI, INC. 













































